Red Hat Bugzilla – Bug 503407
RFE: Autostart delay: need to add user selectable delay to virtual machine autoboot
Last modified: 2016-03-20 18:41:09 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):
Steps to Reproduce:
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
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.
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.
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.
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:
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