[libvirt] [PATCH v3 00/48] Split the libvirtd daemon into per-driver daemons

Daniel P. Berrangé berrange at redhat.com
Tue Jul 30 10:18:38 UTC 2019


On Tue, Jul 30, 2019 at 12:13:30PM +0200, Christophe de Dinechin wrote:
> 
> 
> > On 30 Jul 2019, at 11:38, Daniel P. Berrangé <berrange at redhat.com> wrote:
> > 
> > On Tue, Jul 30, 2019 at 11:05:25AM +0200, Christophe de Dinechin wrote:
> >> 
> >> Daniel P. Berrangé writes:
> >> 
> >>> This is what all the driver refactoring I've done has been about
> >>> enabling.
> >>> 
> >>> We gain new daemons for each driver, for the primary virt drivers:
> >>> 
> >>>  virtlibxld
> >> 
> >> virtxend?
> >> 
> >>>  virtlxcd
> >>>  virtqemud
> >>>  virtvboxd
> >>>  virtvzd
> >>> 
> >>> And again for the secondary drivers
> >>> 
> >>>  virtinterfaced
> >>>  virtnetworkd
> >>>  virtnodedevd
> >>>  virtnwfilterd
> >>>  virtsecretd
> >>>  virtstoraged
> >>> 
> >>> Finally to support IP connectivity, and also the legacy lbivirtd UNIX
> >>> domain socket (for the old libvirt remote driver SSH tunnelling):
> >>> 
> >>>  virtproxyd
> >>> 
> >>> The the sake of facilitating upgrades, the existing libvirtd still
> >>> exists and works the same way it always has.
> >>> 
> >>> You either run libvirtd, or you run the per-driver daemons, never both.
> >> 
> >> What happens if you run both?
> >> (I'll try to figure out by reviewing the rest of the code and/or testing)
> > 
> > The drivers acquire an exclusive lock, causing the 2nd daemon to fail
> > to startup
> > 
> > $ ./src/libvirtd &
> > 
> > $ ./src/virtqemud 
> > 2019-07-30 09:36:34.339+0000: 22809: info : libvirt version: 5.6.0
> > 2019-07-30 09:36:34.339+0000: 22809: info : hostname: dhcp-16-132.lcy.redhat.com
> > 2019-07-30 09:36:34.339+0000: 22809: error : virPidFileAcquirePath:376 : Failed to acquire pid file '/run/user/501/libvirt/qemu/run/driver.pid': Resource temporarily unavailable
> > 2019-07-30 09:36:34.339+0000: 22809: error : virStateInitialize:688 : Initialisation of QEMU state driver failed: Failed to acquire pid file '/run/user/501/libvirt/qemu/run/driver.pid': Resource temporarily unavailable
> > 2019-07-30 09:36:34.339+0000: 22809: error : daemonRunStateInit:821 : Driver state initialisation failed
> > 
> > 
> > The same works the other way around too
> > 
> > $ ./src/virtqemud &
> > 
> > $ ./src/libvirtd
> > 2019-07-30 09:37:45.398+0000: 23109: info : libvirt version: 5.6.0
> > 2019-07-30 09:37:45.398+0000: 23109: info : hostname: dhcp-16-132.lcy.redhat.com
> > 2019-07-30 09:37:45.398+0000: 23109: error : virPidFileAcquirePath:376 : Failed to acquire pid file '/run/user/501/libvirt/qemu/run/driver.pid': Resource temporarily unavailable
> > 2019-07-30 09:37:45.398+0000: 23109: error : virStateInitialize:688 : Initialisation of QEMU state driver failed: Failed to acquire pid file '/run/user/501/libvirt/qemu/run/driver.pid': Resource temporarily unavailable
> > 2019-07-30 09:37:45.398+0000: 23109: error : daemonRunStateInit:821 : Driver state initialisation failed
> > 
> > 
> > 
> > the systemd unit files also have Conflicts rules which should prevent
> > even getting that far
> 
> Thanks for testing. But that can only work for one deamon which shares the lock file
> name with libvirtd. What about the other drivers? I guess they can’t all share the
> same lock file, or I missed something big in the design.

Libvirt has many drivers (qemu, lxc, bhyve, libxl, storage, network).
Each one of these acquires its own lock file under its own private
directory - either /var/run/libvirt/$DRIVERNAME/driver.pid (as root)
or /run/user/$UID/libvirt/$DRIVERNAME/run/driver.pid (as non-root).

Libvirtd loads all the drivers, so will end up holding a lock for
every driver it has loaded.   Each new driver only loads a single
driver and so will hold a single lock.

The daemons themselves also hold their own locks to prevent the
same daemon being started twice.

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




More information about the libvir-list mailing list