Re: Adding suppport for daemon restarts with stateful drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 21, 2008 at 04:50:45PM -0400, Daniel Veillard wrote:
> 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) 

Yes, it is an open question whether it would be neccessary to keep clients
open / functional. I'd probably argue that it should just kick off all
clients when re-exec()ing. Clients can trivially re-connect & the libvirt
API itself is stateless, so dropping & reconnecting is not a particularly
hard thing to deal with from that POV. 

> > 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 ?

The SSL / Kerberos protocols definitely have arbitrary internal state that
would be impossible to preserve.  So if we tried this approach we'd have 
to kill off active clients & let them reconnect.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]