libvirt/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk-usage.args

LC_ALL=C \
PATH=/bin \
HOME=/home/test \
USER=test \
LOGNAME=test \
QEMU_AUDIO_DRV=none \
/usr/bin/qemu-system-i686 \
-name encryptdisk \
-S \
-M pc \
-m 1024 \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 496898a6-e6ff-f7c8-5dc2-3cf410945ee9 \
-nographic \
-nodefaults \
-monitor unix:/tmp/lib/domain--1-encryptdisk/monitor.sock,server,nowait \
-no-acpi \
-boot c \
-usb \
-drive file=/storage/guest_disks/encryptdisk,format=qcow2,if=none,\
id=drive-virtio-disk0 \
-device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,\
id=virtio-disk0 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
util: Add 'usage' for encryption In order to use more common code and set up for a future type, modify the encryption secret to allow the "usage" attribute or the "uuid" attribute to define the secret. The "usage" in the case of a volume secret would be the path to the volume as dictated by the backwards compatibility brought on by virStorageGenerateQcowEncryption where it set up the usage field as the vol->target.path and didn't allow someone to provide it. This carries into virSecretObjListFindByUsageLocked which takes the secret usage attribute value from from the domain disk definition and compares it against the usage type from the secret definition. Since none of the code dealing with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly cosmetic change. The real usage comes in a future path where the encryption is expanded to be a luks volume and the secret will allow definition of the usage field. This code will make use of the virSecretLookup{Parse\|Format}Secret common code. Signed-off-by: John Ferlan <jferlan@redhat.com> 2016-05-30 07:47:46 -04:00			`LC_ALL=C \`
			`PATH=/bin \`
			`HOME=/home/test \`
			`USER=test \`
			`LOGNAME=test \`
			`QEMU_AUDIO_DRV=none \`
tests: unify qemu binary paths for all qemu related tests Our test data used a lot of different qemu binary paths and some of them were based on downstream systems. Note that there is one file where I had to add "accel=kvm" because the qemuargv2xml code parses "/usr/bin/kvm" as virt type="kvm". Signed-off-by: Pavel Hrdina <phrdina@redhat.com> 2017-04-06 18:19:48 +02:00			`/usr/bin/qemu-system-i686 \`
util: Add 'usage' for encryption In order to use more common code and set up for a future type, modify the encryption secret to allow the "usage" attribute or the "uuid" attribute to define the secret. The "usage" in the case of a volume secret would be the path to the volume as dictated by the backwards compatibility brought on by virStorageGenerateQcowEncryption where it set up the usage field as the vol->target.path and didn't allow someone to provide it. This carries into virSecretObjListFindByUsageLocked which takes the secret usage attribute value from from the domain disk definition and compares it against the usage type from the secret definition. Since none of the code dealing with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly cosmetic change. The real usage comes in a future path where the encryption is expanded to be a luks volume and the secret will allow definition of the usage field. This code will make use of the virSecretLookup{Parse\|Format}Secret common code. Signed-off-by: John Ferlan <jferlan@redhat.com> 2016-05-30 07:47:46 -04:00			`-name encryptdisk \`
			`-S \`
			`-M pc \`
			`-m 1024 \`
qemu: caps: Always assume QEMU_CAPS_SMP_TOPOLOGY Support for SMP topology was added by qemu commit dc6b1c09849484fbbc50 prior to 0.12.0, our minimum supported qemu version. $ git describe --tags dc6b1c09849484fbbc50803307e4c7a3d81eab62 v0.11.0-rc0-449-gdc6b1c0 $ git describe --tags --contains dc6b1c09849484fbbc50803307e4c7a3d81eab v0.12.0-rc0~1477 2016-06-23 13:29:16 +02:00			`-smp 1,sockets=1,cores=1,threads=1 \`
util: Add 'usage' for encryption In order to use more common code and set up for a future type, modify the encryption secret to allow the "usage" attribute or the "uuid" attribute to define the secret. The "usage" in the case of a volume secret would be the path to the volume as dictated by the backwards compatibility brought on by virStorageGenerateQcowEncryption where it set up the usage field as the vol->target.path and didn't allow someone to provide it. This carries into virSecretObjListFindByUsageLocked which takes the secret usage attribute value from from the domain disk definition and compares it against the usage type from the secret definition. Since none of the code dealing with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly cosmetic change. The real usage comes in a future path where the encryption is expanded to be a luks volume and the secret will allow definition of the usage field. This code will make use of the virSecretLookup{Parse\|Format}Secret common code. Signed-off-by: John Ferlan <jferlan@redhat.com> 2016-05-30 07:47:46 -04:00			`-uuid 496898a6-e6ff-f7c8-5dc2-3cf410945ee9 \`
			`-nographic \`
			`-nodefaults \`
			`-monitor unix:/tmp/lib/domain--1-encryptdisk/monitor.sock,server,nowait \`
			`-no-acpi \`
			`-boot c \`
			`-usb \`
			`-drive file=/storage/guest_disks/encryptdisk,format=qcow2,if=none,\`
			`id=drive-virtio-disk0 \`
			`-device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,\`
			`id=virtio-disk0 \`
			`-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3`