[libvirt-users] Fail in virDomainUpdateDeviceFlags (libvirt-4.0.0 + Qemu-kvm 2.9.0 + Ceph 10.2.10)

[John Ferlan]

On 03/02/2018 08:28 AM, Peter Krempa wrote:
> On Tue, Feb 27, 2018 at 09:53:00 +0100, Michal Privoznik wrote:
>> On 02/27/2018 03:06 AM, Star Guo wrote:
>>> Hello Everyone,
>>>
>>>  
>>>
>>> My pc run in CentOS 7.4 and install libvirt-4.0.0 + Qemu-kvm 2.9.0 + Ceph
>>> 10.2.10 ALL-in-One.
>>>
>>>  
>>>
>>> I use python-sdk with libvirt and run [self.domain.updateDeviceFlags(xml,
>>> libvirt.VIR_DOMAIN_AFFECT_LIVE)] on CDROM (I want to change media path).
>>> However, I enable libvirt debug log , the log as below:
>>>
>>> <snip/>
>>>
>>> I see the flow is virDomainUpdateDeviceFlags -> qemuMonitorChangeMedia, but
>>> the cephx auth is drop, so make update error. Anybody meet this error? 
>>
>> Yes, this is a libvirt bug. I think this fixes the issue:
>>
>> diff --git i/src/qemu/qemu_driver.c w/src/qemu/qemu_driver.c
>> index 96454c17c..0e5ad9971 100644
>> --- i/src/qemu/qemu_driver.c
>> +++ w/src/qemu/qemu_driver.c
>> @@ -7842,6 +7842,8 @@ qemuDomainChangeDiskLive(virDomainObjPtr vm,
>>                           virQEMUDriverPtr driver,
>>                           bool force)
>>  {
>> +    virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
>> +    qemuDomainObjPrivatePtr priv = vm->privateData;
>>      virDomainDiskDefPtr disk = dev->data.disk;
>>      virDomainDiskDefPtr orig_disk = NULL;
>>      virDomainDeviceDef oldDev = { .type = dev->type };
>> @@ -7850,6 +7852,9 @@ qemuDomainChangeDiskLive(virDomainObjPtr vm,
>>      if (virDomainDiskTranslateSourcePool(disk) < 0)
>>          goto cleanup;
>>  
>> +    if (qemuDomainPrepareDiskSource(disk, priv, cfg) < 0)
>> +        goto cleanup;
> 
> It's not that easy. At this point you also need to hotplug the 'secret'
> object. Without that the command will fail as the secret object
> referenced by the storage source definition will not be present.
> 

Just because it may not be obvious that the thread forked (probably
email client for original poster)... Anyway, see what ended up being a
longer explanation here:

https://www.redhat.com/archives/libvirt-users/2018-February/msg00086.html

Where the short story is I don't think you need to hotplug a secret
object as that should already be there. One cannot hotplug a cdrom, so
the definition and the secret used must already exist. It's a strange
code path and while looking I didn't find a mechanism that would allow
an "empty" or "tray='open'" to actually create a dummy entry.

I believe there needs to be a way via the (newer, but not supported in
libvirt) blockdev-change-medium qmp command to tell it what the secret
object id is.

> There should be a upstream bugzilla tracking this and I'm planing to fix
> this during my work on using the new blockdev stuff in qemu.
> 

And yes, bzs would be good to track all this.

John