Re: [libvirt] [Libvirt-ci] Build failed in Jenkins: libvirt-daemon-check » libvirt-centos-6 #1473
Hi John, On Tue, Jul 19, 2016 at 02:58:06PM +0000, ci@centos.org wrote:
See <https://ci.centos.org/job/libvirt-daemon-check/systems=libvirt-centos-6/1473/>
This failure points to the LUKS patches. 372) QEMU XML-2-ARGV luks-disks ... In '/home/jenkins/libvirt/systems/libvirt-centos-6/tests/qemuxml2argvdata/qemuxml2argv-luks-disks.args': Offset 0 Expect [LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none /usr/bin/qemu -name encryptdisk -S -object secret,id=masterKey0,format=raw,file=/tmp/lib/domain--1-encryptdisk/master-key.aes -M pc-i440fx-2.1 -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 -object secret,id=virtio-disk0-luks-secret0,data=9eao5F8qtkGt+seB1HYivWIxbtwUu6MQtg1zpj/oDtUsPr1q8wBYM91uEHCn6j/1,keyid=masterKey0,iv=AAECAwQFBgcICQoLDA0ODw==,format=base64 -drive file=/storage/guest_disks/encryptdisk,key-secret=virtio-disk0-luks-secret0,format=luks,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -object secret,id=virtio-disk1-luks-secret0,data=9eao5F8qtkGt+seB1HYivWIxbtwUu6MQtg1zpj/oDtUsPr1q8wBYM91uEHCn6j/1,keyid=masterKey0,iv=AAECAwQFBgcICQoLDA0ODw==,format=base64 -drive file=/storage/guest_disks/encryptdisk2,key-secret=virtio-disk1-luks-secret0,format=luks,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 ] Actual [LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none /usr/bin/qemu -name encryptdisk -S -object secret,id=masterKey0,format=raw,file=/tmp/lib/domain--1-encryptdisk/master-key.aes -M pc-i440fx-2.1 -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,key-secret=AQCVn5hO6HzFAhAAq0NCv8jtJcIcE+HOBlMQ1A,format=luks,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/storage/guest_disks/encryptdisk2,key-secret=AQCVn5hO6HzFAhAAq0NCv8jtJcIcE+HOBlMQ1A,format=luks,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3] ... FAILED Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 07/19/2016 11:08 AM, Daniel P. Berrange wrote:
Hi John,
On Tue, Jul 19, 2016 at 02:58:06PM +0000, ci@centos.org wrote:
See <https://ci.centos.org/job/libvirt-daemon-check/systems=libvirt-centos-6/1473/>
This failure points to the LUKS patches.
372) QEMU XML-2-ARGV luks-disks ... [...] ... FAILED
Regards, Daniel
Ugh! Reused the qemuDomainSecretSetup in order to create; however, unlike the previous code to encrypt the secret with the master key, there is no fallback to use a plaintext secret to access a luks disk. I can tell it's using the plaintext secret because of the ",key-secret=AQCVn5hO6HzFAhAAq0NCv8jtJcIcE+HOBlMQ1A" where that's supposed to be the "alias" of the master key encrypted secret. The second field of _qemuDomainSecretPlain is the secret while the second field of _qemuDomainSecretAES is the alias. So the "fix" would be to error out if we set up a plain text secret. Still that doesn't fix 'everything'.... The qemuxml2argvtest code would then unexpectedly fail, so adding an ifdef there similar to the counterpart for an rbd-auth-AES secret would at least test the new logic. Finally, on the luks disk create side, I did generate a temporary file to store the encoded secret since it was felt that generating the aes secret with the master key was overkill. However, since usage will require the master key encrypted secret, adding a check there to avoid a future failure would seem appropriate. Patches are "on the way" shortly. John FWIW: While it would be possible to create a file to store the encoded secret and then use that file on the qemu command line, earlier decisions seemed to have rendered that as a non option. Especially since that file would need to stick around and would have "just" a base64 encoded secret in it.
participants (2)
-
Daniel P. Berrange -
John Ferlan