
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@redhat.com> --- src/conf/domain_conf.c | 129 +++++++++++++++++++++++++ src/libvirt_private.syms | 1 + src/qemu/qemu_block.c | 1 + src/qemu/qemu_command.c | 1 + src/qemu/qemu_driver.c | 4 + src/qemu/qemu_migration.c | 1 + src/util/virstoragefile.c | 59 +++++++++++ src/util/virstoragefile.h | 15 +++ src/xenconfig/xen_xl.c | 1 + tests/qemuxml2argvdata/disk-nvme.xml | 12 ++- tests/qemuxml2xmloutdata/disk-nvme.xml | 1 + tests/qemuxml2xmltest.c | 1 + 12 files changed, 224 insertions(+), 2 deletions(-) create mode 120000 tests/qemuxml2xmloutdata/disk-nvme.xml
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 3323c9a5b1..73f5e1fa0f 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -5088,6 +5088,11 @@ virDomainDiskDefPostParse(virDomainDiskDefPtr disk, return -1; } + if (disk->src->type == VIR_STORAGE_TYPE_NVME) { + if (disk->src->nvme->managed == VIR_TRISTATE_BOOL_ABSENT) + disk->src->nvme->managed = VIR_TRISTATE_BOOL_YES; + } + if (disk->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE && virDomainDiskDefAssignAddress(xmlopt, disk, def) < 0) { return -1; @@ -5938,6 +5943,38 @@ virDomainDiskDefValidate(const virDomainDiskDef *disk) return -1; } + if (disk->src->type == VIR_STORAGE_TYPE_NVME) {
Note that this can potentially happen in the backing chain as well, so this should be checked throughout the whole backing chain.
Is that so? I mean, other checks done in this funtion check only 'top level' disk->src too.
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.