On 7/16/19 2:38 PM, Peter Krempa wrote:
On Thu, Jul 11, 2019 at 18:16:58 +0200, Peter Krempa wrote:
On Thu, Jul 11, 2019 at 18:12:16 +0200, Michal Privoznik wrote:
On 7/11/19 6:05 PM, Peter Krempa wrote:
On Thu, Jul 11, 2019 at 17:53:58 +0200, Michal Privoznik wrote:
To simplify implementation, some restrictions are added. For
instance, an NVMe disk can't go to any bus but virtio and has to
be type of 'disk' and can't have startupPolicy set.
Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
---
[...]
Yes it certainly will be possible with blockdev. Also you have such a
file in the backing chain which gets detected from the file metadata on
the disk, so such a check will probably need to be duplicated also when
starting the VM (the validate callback function may be better match).
Also this seems all to belong to the qemu specific post parse callback.
Possibly. But since other drivers would still use virNVMeDevice module I'm
adding later in this series, and since the module is build on these
assumptions I figured the best place to check for them is in driver agnostic
callback.
Fair enough.
Thinking about this a bit more, if there will be a separate module for
this, that module should expose the validator.
Well, the module sees virNVMeDevice struct and not virDomainDiskDef
(these are two different structures). And since we do not want code from
src/util/ include anything in src/conf/ I'm not quite sure how to access
virDomainDiskDef from src/util/virnvme.c.
Also I'm not persuaded
about the universality of this code at all thus I doubt that it will be
reused in other hypervisors as it requires a userspace driver for NVMe
in the hypervisor, which is a pretty niche configuraion/use case.
Well, nearly everything that we work on is qemu specific, because quite
frankly, we only touch other drivers when an internal API is changed and
a codebase wide adoption is needed.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
