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

Christophe de Dinechin dinechin at redhat.com
Tue Jul 30 10:13:30 UTC 2019



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

(Sorry, still reviewing, so did not really have time to try it yet)

> 
> 
> 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 :|
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list





More information about the libvir-list mailing list