Bug 503407

Okay, this was discussed on list and I think the conclusion is to not add this "delay" feature to autostart:

  http://www.redhat.com/archives/libvir-list/2009-May/msg00566.html

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

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


Regards,
Gerry

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.

Hi,

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.

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:
https://bugzilla.redhat.com/show_bug.cgi?id=695653

More info on the order in which libvirt-guests starts VMs can be found here:
https://www.redhat.com/archives/libvir-list/2011-April/msg00819.html

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?

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