Re: Best practices to handle shared objects through qemu upgrades?

[Daniel P . Berrangé]

On Fri, Nov 01, 2019 at 10:55:29AM +0100, Christian Ehrhardt wrote:
> On Fri, Nov 1, 2019 at 10:34 AM Daniel P. Berrangé <address@hidden> wrote:
> >
> > On Fri, Nov 01, 2019 at 08:14:08AM +0100, Christian Ehrhardt wrote:
> > > Hi everyone,
> > > we've got a bug report recently - on handling qemu .so's through
> > > upgrades - that got me wondering how to best handle it.
> > > After checking with Paolo yesterday that there is no obvious solution
> > > that I missed we agreed this should be brought up on the list for
> > > wider discussion.
> > > Maybe there already is a good best practise out there, or if it
> > > doesn't exist we might want to agree upon one going forward.
> > > Let me outline the case and the ideas brought up so far.
> > >
> > > Case
> > > - You have qemu representing a Guest
> > > - Due to other constraints e.g. PT you can't live migrate (which would
> > > be preferred)
> > > - You haven't used a specific shared object yet - lets say RBD storage
> > > driver as example
> > > - Qemu gets an update, packaging replaces the .so files on disk
> > > - The Qemu process and the .so files on disk now have a mismatch in 
> > > $buildid
> > > - If you hotplug an RBD device it will fail to load the (now new) .so
> >
> > What happens when it fails to load ?  Does the user get a graceful
> > error message or does QEMU abort ? I'd hope the former.
> >
> 
> It is fortunately a graceful error message, here an example:
> 
> $ virsh attach-device lateload curldisk.xml
> Reported issue happens on attach:
> root@b:~# virsh attach-device lateload cdrom-curl.xml
> error: Failed to attach device from cdrom-curl.xml
> error: internal error: unable to execute QEMU command 'device_add':
> Property 'virtio-blk-device.drive' can't find value
> 'drive-virtio-disk2'

Ok, that's graceful, but horrifically useless as an error message :-)

I'd like to think there would be a way to do better.

It looks like the 'drive-add' (or whatever we run to add the
backend) is failing, and then we blindly run device_add anyway.

This means either there's some error message printed that we
are missing, or QEMU is not reporting it back to the monitor.
Either way, I think this can be improved so that libvirt can
directly report the message you found hidden in the log:

> 
> In the qemu output log we can see:
> Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-curl.so
> Note: only modules from the same build can be loaded.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|