[libvirt] [Libvirt-ci] Build failed in Jenkins: libvirt-daemon-check » libvirt-centos-6 #1473

[John Ferlan]

On 07/19/2016 11:08 AM, Daniel P. Berrange wrote:
> Hi John,
> 
> On Tue, Jul 19, 2016 at 02:58:06PM +0000, ci at 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.