On Thu, 2018-08-23 at 12:13 +0000, Inception Hosting wrote:
just a followup with more information:
Please don't top post on technical mailing lists.
The approach I have tried is to update /etc/sysconfig/libvirt-guests
as follows:
[...]
# action taken on host boot
# - start all guests which were running on shutdown are started on boot
# regardless on their autostart settings
# - ignore libvirt-guests init script won't start any guest on boot, however,
# guests marked as autostart will still be automatically started by
# libvirtd
ON_BOOT=ignore
As explained in the comment above it, this setting tells the
libvirt-guests script not to start guests during boot, so I'm not
very surprised further settings...
# Number of seconds to wait between each guest start. Set to 0 to
allow
# parallel startup.
START_DELAY=180
... like this one are not being honored :)
[...]
I have verified the default URIs path in libvirt.conf is correct
also
and have tried changing the default in the above config file to
qemu:///system & qemu:///
All the guests boot at the same time regardless of changes made.
I have also tried removing the contents of
/etc/libvirt/qemu/autostart/ incase the symbolic links were overriding
the libvirt-guests config however nothing starts then (not
surprising).
You shouldn't poke at the filesystem behind libvirt's back: please
use 'virsh autostart' instead.
Basically in your current setup guests are not started at boot by
the libvirt-guests script but by libvirtd itself; the former
supports adding a delay between starting a guests and starting the
next one, but the latter AFAIK doesn't.
To be honest, the libvirt-guests script and particularly its
interaction with libvirtd's own autostart feature are kind of a
mess, one that is not well documented and that I don't think we
can fix without breaking backwards compatibility.
In particular, what you are trying to achieve is simply not
possible without implementing your own scripts, at least to the
best of my knowledge. Hopefully someone will prove me wrong, but
I really wouldn't count too much on it :(
--
Andrea Bolognani / Red Hat / Virtualization