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 ?