[libvirt] RFC: Post-install behavior of libvirt(-client)

Eric Blake eblake at redhat.com
Tue Feb 14 22:17:40 UTC 2012

On 02/14/2012 01:37 AM, Martin Kletzander wrote:
> Hello everyone,
> I have a small bug #786770 [1] assigned and I discussed this with few
> people from our team but I'm still not sure what should be the proper
> fix for this bug.

> Thinking about this a little more, I see two more "unconsistencies"
> let's say:
>  - we are starting libvirt-guests if it is enabled (rpm post script
> should not start services)

Ultimately, I see two possible useful behaviors:

1. We install but don't start services.  Since both libvirtd and
libvirt-guests have a Default-Start: 3 4 5 (for init script) or
[Install]WantedBy=multi-user.target (for systemd), then the user will
get both services running after their next reboot (by virtue of their
defaults), but not beforehand.

If the user wants to start the services before rebooting, then they
should start both services - if the user starts libvirtd but not
libvirt-guests, it is their own fault for not realizing that
libvirt-guests was useful.

2. We install services, and if it is the initial install, we also
default those services to start immediately.  And, since libvirt-client
can be installed without libvirtd, we make sure that the libvirt-guests
init script has sane default behavior when it cannot connect to a
running libvirtd.

Where is it written that rpms may not start services?  Finding a
concrete policy on the matter should influence our answer...

>  - we don't check if libvirtd is running, so during shutdown we can get
> even more error messages that the script is not able to connect to
> libvirt etc.

That's a service dependency - if both libvirt-guests and libvirtd are
installed services, then starting libvirt-guests should automatically
start libvirtd first (that is, assuming the default libvirt-guests
behavior of probing local URIs that require libvirtd).  I think that is
done by a Should-Start: libvirt-guests in the init version (oops, that's
missing), and by [Unit]Before=libvirt-guests.service in the systemd
version.  Meanwhile, the dependency must be weak; either libvirtd or
libvirt-guests in isolation makes sense (well, libvirt-guests in
isolation is less likely, since then it can only manage remote URIs, but
should still be possible).

> So I'm wondering if I can just remove the starting part (because if
> someone wants to use it after first install, he has to start libvirtd
> anyway and then should know to start libvirt-guests as well) or if I
> have to come up with some totally different solution how to do this.
> Maybe I'm missing something here or I don't understand it correctly, any
> correction is appreciated.
> Thanks in advance for all suggestions.

Other food for thought - now that we switched libvirt to systemd init
scripts in F16, we should be creating new libvirt-sysvinit and
libvirt-client-sysvinit packages for the init scripts:


That page also states:

>> Why don't we....
>>     run 'chkconfig <service> on'? 
>> If a service should be enabled by default, make this the default in the init script. Doing otherwise will cause the service to be turned on on upgrades if the user explicitly disabled it.
>> Note that the default for most network-listening scripts is off. This is done for better security. We have multiple tools that can enable services, including GUIs.
>>     start the service after installation? 
>> Installations can be in changeroots, in an installer context, or in other situations where you don't want the services started. 

with a similar wording for systemd:


>> Why don't we....
>>     Start the service after installation? 
>> Installations can be in changeroots, in an installer context, or in other situations where you don't want the services autostarted. 

libvirtd is network-listening, libvirt-guests is not; but libvirt-guests
without libvirtd isn't quite as useful.

I'm starting to lean towards option 1 - we should install, but not
start, services.

But there might be another option for systemd: if we make
libvirtd.service support socket-activation _in addition to_ boot
activation, then we could make things so that the first 'virsh -c
qemu:///system' starts up libvirtd, if it is not already running, as
well as the fact that we want libvirtd to start at boot in order to
start any autostart domains without waiting for a socket connection.
I'm not sure how much additional work that would be (certainly beyond
the scope of your initial question of how to silence the messages during
rpm installation due to mis-use of chkconfig).  And if we _do_ make
libvirtd socket-activated, then we have to figure out how to make
libvirt-guests start at the same time.

Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120214/47a854da/attachment-0001.sig>

More information about the libvir-list mailing list