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é <berra...@redhat.com> > 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 :|
