On 03-07-12 15:13, Daniel P. Berrange wrote:
That is really bizarre. Can you look at what is actually stored in the .base64 file each time ? And what 'secret-get-value' replies with ?
I haven't been able to look into this any further, however: I just downloaded 0.9.13 from the libvirt website and installed it on a totally different host which is also running Ubuntu 12.04
I wanted to start a virtual machine with RBD storage and that failed, the secret was corrupted...
The symptoms on this machine are exactly the same, the secret file is just 2 bytes big.
root@amd:~# ls -al /etc/libvirt/secrets/*.base64 -rw------- 1 root root 2 Jul 3 15:02 /etc/libvirt/secrets/69f9540e-f0ce-4184-8254-9b22efade5f2.base64 root@amd:~#
This is the correct behaviour tht I see myself too.
I verified that stack01 isn't out of disk space or out of inodes, those are in the acceptable values range.
Any suggestions?
I think you'll probably need to add some more VIR_DEBUG lines to secret_driver.c to see where in the process it is going wrong. Or perhaps strace libvirtd to see what it thinks it is writing out & whether any errors appear.
I haven't added any VIR_DEBUG lines yet, but stracing the libvirtd process doesn't show any fopen() nor fwrites() to any *.base64 files.
I just added a couple of VIR_DEBUG lines to secret_driver.c and found out that the base64 encoding is actually the problem. In secretSaveValue VIR_DEBUG("WIDO Secret value: %s, size %lu", secret->value, secret->value_size); filename = secretBase64Path(driver, secret); if (filename == NULL) goto cleanup; base64_encode_alloc((char *)secret->value, secret->value_size, &base64); if (base64 == NULL) { virReportOOMError(); goto cleanup; } VIR_DEBUG("WIDO Writing %s to %s with a length of %lu", base64, filename, strlen(base64)); if (replaceFile(filename, base64, strlen(base64)) < 0) goto cleanup; The results I get back: $ virsh secret-set-value 322bccea-f2ed-4eae-a7e5-d0793ffb162d d2lkbw== 2012-07-03 14:02:57.065+0000: 4593: debug : secretSaveValue:297 : WIDO Secret value: wido, size 4 2012-07-03 14:02:57.065+0000: 4593: debug : secretSaveValue:309 : WIDO Writing ��� to /etc/libvirt/secrets/322bccea-f2ed-4eae-a7e5-d0793ffb162d.base64 with a length of 6 Here you can see the secret value arrives at the secret driver in tact, but the base64_encode_alloc seems to scramble the data. It should display base64 encoded data to write to 'filename', but it's showing some binary stuff. I then tried to shut down libvirt, manually write the base64 data to the file and start libvirt again: loadSecrets:510 : Error reading secret: internal error invalid base64 in XXX But there is valid base64 data in that file. This seems to be a gnulib thing? The submodule gnulib is used for the base64 encoding, isn't it? Checking the gnulib source shows that there have been no changes to base64.h and .c. The last change is from over a year ago.
When strac'ing libvirtd make sure you add the '-f' arg so that you trace all threads - the libvirtd thread leader will never do any interesting stuff except RPC i/o
Right... My bad :) Wido