Re: [libvirt] [PATCH] qemu: Add ability to disable autostarting of guests on daemon start
On 11/05/12 16:48, Eric Blake wrote:
On 11/05/2012 08:02 AM, Peter Krempa wrote:
> When the daemon is starting it autostarts all guests marked as
> autostartable. This is not an ideal solution for autostarting if there's
> a lot of domains configured so. After autostarting all right away the
> guests start competing for disk I/O and the boot is prolonged
> unnecessarily.
>
> This patch adds a config option to disable autostarting to leave it on
> user scripts that may use mechanisms to reduce load of the host by
> limiting the number of guests started in parallel.
Hmm, this config option effectively renders autostart useless. If
that's the case, I wonder if we should then also forbid people from
using virDomainSetAutostart to turn autostart on for a given domain.
[Reading further - oh, I found your example of 'virsh list --all
--autostart]
I meant this to be exactly this way. The user can use this field as a
metadata field for the script or whatever he is using instead of the
autostart behavior.
I really wonder if a better solution would be to add something to domain
XML that says whether autostart is enabled, and more importantly, gives
a delay for how long after libvirtd starts before that particular
domain's autostart is acted on.
That is, right now, autostart is an invisible property (not present in
virDomainGetXMLDesc; you have to use virDomainGetAutostart to learn
about it), with just a bool value of on or off. But what if we modified
domain XML to display:
<autostart enabled='yes' delay='5'/>
meaning that this domain is set to autostart, but only after 5 seconds
have elapsed since the start of libvirtd?
Hmm, that's strange that we're not exposing the autostart property. I
agree that we should add that. For the delay property, the absolute
meaning is OK if we assume a management application is sitting on top of
libvirt and tweaking those values. But if we have a regular user that
doesn't have an automated magic on top of this, then removing machines
from one of selected time create holes in this scheduling. Also if the
user wishes to allocate more time for a machine to boot, he has to
manually shift other guests away.
>
> Unfortunately, there's no simple way we could do this in libvirt. The
> problem is how to detect that the guest has finished booting as it's
> mostly a black box for libvirt. There area few options:
>
> 1) Wait until I/O load of the guest drops.
> - This is insufficient on guests that do heavy I/O all the time.
>
> 2) Let the guest tell us.
> - Not every OS has the ability to have a guest agent.
Agree that these two won't work.
Well, unless you know what you're doing. If you know that you have guest
agent installed, you might take that into account and actually start the
machines after they stop booting (or some timeout expires - 2+3)
>
> 3) Wait for certain amount of time.
> - Very limited amount of control on diverse guests.
Limited, but at least expressible if you take my idea of exposing an
autostart delay in the domain XML.
>
> With this functionality, the user may write his own script that load
> balances the autostart in a sane way with accordance to his
> infrastructure (Query agents, check I/O, use configurable timeouts)
> while stil being able to mark the domains as autostartable with all the
s/stil/still/
> benefits (virsh list --all --autostart).
If you use the config option to disable autostart, then there is no
autostart. But I guess I see where you are coming from for at least
allowing the designation, even if libvirtd won't honor it, so that you
can at least filter domains based on those that were marked.
And you can use the result of the list query to start them in the script
or manualy.
I also wonder if Michal's suggestion of making it a command-line option
rather than a config option is better - how easy or hard is it to inject
additional command line options into a systemd startup script?
Hm the harder part here is to propagate the values from commandline to
the drivers. We'd need to modify the driver registration function to
allow us passing arguments. That's the reason I chose qemu.conf.