On Fri, Mar 21, 2008 at 05:35:12PM +0000, Daniel P. Berrange wrote:
The libvirt daemon has the ability to reload itself by sending it
SIGHUP.
For the QEMU & network drivers this makes it reload the config files for
VMs and re-init the iptables rules. It would be desirable though to allow
the daemon to perform a full restart. Principally this is for RPM upgrades
where you want toensure the daemon is running the new code.
The tricky thing is figuring out how to handle driver state. Looking at the
QEMU, network, storage and LXC drivers, there is not actually all that much
state to deal with. It basically comes down to:
- PID of child processes (eg QEMU, dnsmasq, container)
- FDs for STDIN/OUT/ERR of the child processes
- A possible logfile FD
- Flag to indicate whether some objects are active or not
That is more or less it. Anything else is kept in the config files and can
be reloaded at will.
From a libvirt client connected to the driver POV we would still either
see a disconnection or a potential loss of state depending how they are
connected, right ? if we are sure we can transparently restart fine, but
I'm not sure it's always the case for say an ssh connection without an agent,
still being able to re-exec on the new code is important, I would still try to
avoid it if we can detect the code itself didn't change (for example if the
timestamp on the /usr/sbin/libvirtd didn't change it's likely to be a simple
reload -HUP command)
So I was thinking about whether we could provide a simple protocol to
allow
each stateful driver to save its state into some location, the daemon could
just 'exec()' itself again, and upon startup the drivers reload their active
state. Since the daemon just exec()'s itself it would still own the child
processes & still have all the neccessary FD's open.
yes but how much state is kept in buffers and code of the protocols ?
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/