Bug 503407 - RFE: Autostart delay: need to add user selectable delay to virtual machine autoboot
RFE: Autostart delay: need to add user selectable delay to virtual machine au...
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
: Reopened
Depends On:
Blocks: libvirtTodoHV
  Show dependency treegraph
Reported: 2009-05-31 16:03 EDT by Gerry Reno
Modified: 2016-03-20 18:41 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-03-20 18:41:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gerry Reno 2009-05-31 16:03:26 EDT
Description of problem:
Right now when multiple guests all try to boot at the same time it takes about 4 times as long for all of them to boot up as when you boot them individually.  Apparently too much context switching.  So if we could check off an autoboot flag and then say +120 seconds, that guest would start booting 120 seconds after the autoboot process started.  Even this simple mechansim would help quite a bit.

(from the staggered guest startup thread in the libvir list)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Mark McLoughlin 2009-06-05 05:48:32 EDT
Okay, this was discussed on list and I think the conclusion is to not add this "delay" feature to autostart:


So, I'm closing this was WONTFIX.

The interesting problem here is "starting guests at the same time takes four times longer than starting them individually", and that's something we'd like to fix at the KVM level.

Perhaps you could you do some timing experiments on this and file a new bug against qemu with your results? Thanks
Comment 2 Gerry Reno 2009-06-05 13:34:41 EDT
  I didn't get that impression from the list at all.  The last comment from Daniel Berrange was that doing the staggered startup would be difficult but after I came back with the simple suggestion of just adding a delay that seemed to be more doable.

  We absolutely need this type of mechanism at a minimum to control how these VM's startup.  We need to set the *order* in which they startup.  It's not just a matter of the amount of time involved.

  Please reconsider and reopen this bug.

Comment 3 Mark McLoughlin 2009-06-08 07:30:17 EDT
Okay, maybe that is what Dan is saying with:

  "It doesn't so much suggest the provision of guest startup ordering,
   but rather the serialization of guest startup"

Moving to the upstream libvirt bug tracker.

Again, though, if you can show some detailed results on guests starting up at the same time taking four times longer than guests started sequentially, it'd be very useful to open another bug with that data.
Comment 4 Nico Prenzel 2010-10-15 17:43:18 EDT

any further progess with the guest autostart delay?
This feature would be really needed for example for larger network infrastructure setups, as sometimes one guest provides some network features needed by another guest at startup time.

Just my two cents.
Comment 5 Alexander Todorov 2011-05-04 07:08:01 EDT
Hi guys,
recently I submitted a patch against libvirt-guests script which adds a start delay parameter. The script already had a shutdown timeout parameter. I think this is sufficient to fix/workaround the problem where you don't want all the virtual systems to start at once. More info and links:

More info on the order in which libvirt-guests starts VMs can be found here:
Comment 6 Alexander Todorov 2011-05-04 07:10:35 EDT
My questions:

1) I've added the start delay feature because I also saw guests booting slowly when all started at once compared to when started one by one. I can test and provide more feedback if this is still an issue. (haven't done any measurement.it's only my impression that it takes more time)

2) What's the status of the ordering feature? I don't see this available upstream. While it could be unreliable some commercial vendors offer start/stop ordering feature in their products. What's the plan for libvirt?
Comment 7 Cole Robinson 2016-03-20 18:41:09 EDT
IMO the libvirt autostart feature is just meant to be a very bare bones convenience helper. It's not even clear really where we would add a 'delay' type specification anyways, since autostart has no configuration and is just a wrapper around creating a symlink.

Once we get into the business of trying to extend autostart to handle various ordering issues IMO it's going to turn into a very slippery slope that is better handled by higher level tools, or custom init scripts, or even something like systemd units per VMs.

However extending libvirt-guests startup script may be acceptable to upstream, but for that please file new bug reports

Closing as WONTFIX

Note You need to log in before you can comment on or make changes to this bug.