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

[Peter Krempa]

On Mon, Mar 05, 2018 at 11:11:37 -0500, John Ferlan wrote:
> 
> 
> On 03/05/2018 03:47 AM, Peter Krempa wrote:
> > On Fri, Mar 02, 2018 at 15:32:44 -0500, John Ferlan wrote:
> >>
> >>
> >> 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
> > 
> > No, no, no. That is plain wrong. The secret object is property of the
> > image and not the drive. If you change the image you need to unplug all
> > old encryption and authentication secrets and plug back new ones.
> 
> Well... Kind of... Perhaps it's a matter of how I phrased things. Yes, I
> agree the secret is associated with the image and not the drive;
> however, the image is part of the drive command. So while technically
> there is a split, my description didn't make that distinction mainly
> because when it comes to the change commands all that matters is the
> "filename" (or target) that's being changed and not the server. Since,

So this is again misleading. The qemu blockdev-change-medium does not
only change the "filename" of the image on the same server. The filename
argument is a new full target specification including the server. So
anything you provide is a new image regardless of whether it changed
server or not.

> the authentication is to/for the server and changing the "filename" does
> not make it possible to change the "server", just which file on the
> server is being used.

That does not matter. It's a different image even on the same server. It
can require different authentication or encryption. The fact that in
this case it's on the same server with the same authentication does not
help much in the general case.

Note that even the libvirt API accepts the full XML, so you can specify
any possible image.

> Thus, even if you unplugged the old encryption and authentication secret
> and plugged a new one in, AFAICT the "blockdev-change-medium" command
> provides no mechanism to use the secrets. There is no parsing of server
> and secret options.

That's true. We need to use 'x-blockdev-insert-medium' which uses
blockdev-add and node-names.

Note that 'blockdev-change-medium' documents that it's just a
combination of blockdev-open-tray, x-blockdev-remove-medium,
x-blockdev-insert-medium and blockdev-close-tray.

(Also technically it does provide a way to pass secret, since
'filename' is passed to bdrv_open thus you can pass the JSON
pseudo-protocol spec to it.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20180305/da806644/attachment.sig>