On Tue, Mar 10, 2020 at 09:39:10AM +0000, Stefan Hajnoczi wrote: > On Fri, Mar 06, 2020 at 02:26:48PM +0100, Christian Ehrhardt wrote: > > On upgrades the old .so files usually are replaced. But on the other > > hand since a qemu process represents a guest instance it is usually kept > > around. > > > > That makes late addition of dynamic features e.g. 'hot-attach of a ceph > > disk' fail by trying to load a new version of e.f. block-rbd.so into an > > old still running qemu binary. > > > > This adds a fallback to also load modules from a versioned directory in the > > temporary /var/run path. That way qemu is providing a way for packaging > > to store modules of an upgraded qemu package as needed until the next > > reboot. > > > > An example how that can then be used in packaging can be seen in: > > https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/log/?h=bug-1847361-miss-old-so-on-upgrade-UBUNTU > > > > Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361 > > Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com> > > --- > > util/module.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > CCing Debian, Fedora, and Red Hat package maintainers in case they have > comments. > > The use of /var/run makes me a little uneasy. I guess it's related to > wanting to uninstall the old package so the .so in their original > location cannot be used (even if they had a versioned path)? > > I'm not a package maintainer though so I hope the others will make > suggestions if there are other solutions :).
My first concern is that this only partially solves the quoted problem. Consider the QEMU RBD module which is /usr/lib64/qemu/block-rbd.so This links to /usr/lib64/librbd.so.1 On host OS upgrade, just before uninstalling old QEMU we copy RBD module into: /var/run/qemu-$VER/block-rbd.so ....but the host OS upgrade also upgrades RBD itself to a new major version which ships /usr/lib64/librbd.so.2 We've got /var/run/qemu-$VER/block-rbd.so saved, but we didn't transitively save all the things that this linked to, so there's no guarantee it will still be possible to load it. IOW, this approach of saving QEMU block modules to a scratch dir works, *provided* everything else that this QEMU block module needs still exists in a compatible form. Some distros may have a policy that no incompatible soname bumps are permitted in updates, but that's not universal. On the other hand this is not a big amount of new code, so is not a huge maint problem even if only a few people ever use it. I would be a bit more comfortable if this search path addition was perhaps enabled by an opt-in configure argument, rather than being always present. I'm also uneasy about the idea of using a search path ordering for doing this. This means that an old running QEMU is always going to first try to load the block-rbd.so from the new QEMU, expect to see that fail, and only then fallback to load the block-rbd.so that actually matches its build. IIRC, we have an embedded build-id in the modules that should guarantee that the first load attempt always fails, but I'm still uneasy about that at a conceptual level. 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 :|
