On Thu, Jul 11, 2019 at 17:54:16 +0200, Michal Privoznik wrote: > Now, that we have everything prepared, we can generate command > line for NVMe disks. > > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > --- > src/qemu/qemu_block.c | 25 ++++++++- > src/qemu/qemu_command.c | 3 ++ > src/qemu/qemu_process.c | 7 +++ > .../disk-nvme.x86_64-latest.args | 52 +++++++++++++++++++ > tests/qemuxml2argvtest.c | 1 + > 5 files changed, 87 insertions(+), 1 deletion(-) > create mode 100644 tests/qemuxml2argvdata/disk-nvme.x86_64-latest.args Note that when you enable this you did not disallow snapshots (as in creating a local file snapshot on top of the NVMe image) nor implement the backing store string parser for this. This means that once you create the snapshot, restarting the VM will become impossible as we will not be able to parse the backing store string (which is probably a bad idea altogether, since the disk can change PCI addresses in the meanwhile so refering to it via the one stored in the backing file would be wrong anyways). You'll probably need to disable snapshots (see qemuDomainSnapshotPrepareDiskExternalActive) if the even 'domdisk' is NVMe too at least until we enable -blockdev support. Inactive external snapshots should be fine since we validate that only BLOCK and FILE disks are allowed in qemuDomainSnapshotPrepareDiskExternalInactive. At any rate please also add TEST_DISK_TO_JSON case for this in tests/qemublocktest.c Alternatively depending on how much we want to prevent from parsing nvme:// from the backing store string we'll also need changes to virStorageSourceNewFromBackingAbsolute which will deny the nvme backing store. The unfortunate part is that doing all these limitations basically removes all the advantages of using NVMe disks via the qemu block layer.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
