From: qi.fuli(a)fujitsu.com <qi.fuli(a)fujitsu.com>
Sent: Thursday, February 21, 2019 12:40 AM
> ...
> + /*
> + * Hyper-V Virtual NVDIMM doesn't use ND_CMD_SMART to get the
> health info. Instead, it uses ND_CMD_CALL, so the checking here can't
> + * apply, and it doesn't support threshold alarms -- actually it only
> + * supports one event: ND_EVENT_HEALTH_STATE.
> + */
> + if (ndctl_dimm_get_cmd_family(dimm) == NVDIMM_FAMILY_HYPERV) {
> + if (monitor.event_flags != ND_EVENT_HEALTH_STATE) {
> + monitor.event_flags = ND_EVENT_HEALTH_STATE;
> +
> + notice(&monitor, "%s: only dimm-health-state can be
> monitored\n", name);
Hi Dexuan,
I think that "monitor" should be a "read-only" command and can't
force the
users to change their options.
The monitor.event_flags will work for all NVDIMMs to be monitored.
I don't know whether a physical NVDIMM could be mounted on the OS
running inside of a virtual machine.
If yes, this forced changing may cause an exception of monitoring smart
threshold events on NVDIMM.
Thanks,
Qi
Hi Qi,
Generally speaking, I agree with you, but here the fact is that we can only
monitor this one single event "dimm-health-state" for Hyper-V Virtual NVDIMM,
and the other events are meaningless for Hyper-V Virtual NVDIMM, as they're
not supported by Hyper-V Virtual NVDIMM.
So, if the user specifies more events than just "dimm-health-state", or the
user
doesn't specify "dimm-health-state", it's reasonable to force
monitor.event_flags
to equal to ND_EVENT_HEALTH_STATE, and I explicitly print a warning.
The line "monitor.event_flags = ND_EVENT_HEALTH_STATE" only runs in a Linux
VM running on Hyper-V. It can't adversely affect bare metal cases. In a Linux
VM on Hyper-V, all the NVDIMMs appearing in the VM are Hyper-V Virtual NVDIMMs.
A physical NVDIMM can't be directly passed through to a VM and the hypervisors
(e.g., Xen, KVM, Hyper-V, Qemu, etc.) have to virtualize it to make it available to a
VM. In a VM, the NVDIMM_FAMILY is NVDIMM_FAMILY_HYPERV only when
the VM runs on Hyper-V.
So I think we should be good. :-)
Thanks,
-- Dexuan