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
On almost any other service than "qemu representing a VM" the answer
is "restart it", some even re-exec in place to keep things up and
running.
Ideas so far:
a) Modules are checked by build-id, so keep them in a per build-id dir on disk
- qemu could be made looking preferred in -$buildid dir first
- do not remove the packages with .so's on upgrades
- needs a not-too-complex way to detect which buildids running qemu processes
have for packaging to be able to "autoclean later"
- Needs some dependency juggling for Distro packaging but IMHO can be made
to work if above simple "probing buildid of running qemu" would exist
b) Preload the modules before upgrade
- One could load the .so files before upgrade
- The open file reference will keep the content around even with the
on disk file gone
- lacking a 'load-module' command that would require fake hotplugs
which seems wrong
- Required additional upgrade pre-planning
- kills most benefits of modular code without an actual need for it
being loaded
c) go back to non modular build
- No :-)
d) anything else out there?
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
