| Summary: | [patch] Implement BOOT_TIMEOUT | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Alexander Todorov <atodorov> | ||||
| Component: | libvirt | Assignee: | Jiri Denemark <jdenemar> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.2 | CC: | crobinso, dallan, dyuan, eblake, mzhan, vbian, xen-maint, yoyzhang | ||||
| Target Milestone: | rc | ||||||
| Target Release: | 6.2 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | libvirt-0.9.1-1.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 695654 (view as bug list) | Environment: | |||||
| Last Closed: | 2011-12-06 11:05:00 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
Please post this patch to libvir-list, so that it can get reviewed for inclusion into the upstream libvirt. Send to the list. Initial upstream submit and feedback at: https://www.redhat.com/archives/libvir-list/2011-April/msg00629.html *** Bug 695654 has been marked as a duplicate of this bug. *** Fixed upstream by v0.9.0-102-gd934bd0:
commit d934bd0a584cd8f6ddfcf63575e63965e9ceb366
Author: Alexander Todorov <atodorov>
Date: Fri Apr 15 11:57:06 2011 +0300
libvirt-guests: implement START_DELAY
Allow libvirt-guests to stage a delay between guest startups,
to avoid system load caused by back-to-back startup.
Verified pass with libvirt-0.9.1-1.el6.x86_64 and libvirt-client-0.9.1-1.el6.x86_64 1. Start 5 guests and mark autostart for them # virsh list --all Id Name State ---------------------------------- 49 rhel61_1 running 50 rhel61_2 running 51 rhel61_3 running 52 rhel61_4 running 53 rhel61_5 running # virsh dominfo rhel61_1 ... Autostart: disable ... 2. Edit /etc/sysconfig/libvirt-guests and set the start delay to 20 seconds # number of seconds to wait between each guest start #START_DELAY=0 START_DELAY=20 3. # service libvirt-guests restart Running guests on default URI: rhel61_1, rhel61_2, rhel61_3, rhel61_4, rhel61_5 Suspending guests on default URI... Suspending rhel61_1: done Suspending rhel61_2: done Suspending rhel61_3: done Suspending rhel61_4: done Suspending rhel61_5: done Resuming guests on default URI... Resuming guest rhel61_1: done Resuming guest rhel61_2: done Resuming guest rhel61_3: done Resuming guest rhel61_4: done Resuming guest rhel61_5: done The start_delay between resuming the 5 guests are 20 seconds Move to Verified according to Comment #7 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1513.html |
Created attachment 491448 [details] patch to implement BOOT_TIMEOUT functionality Description of problem: AFAIK when guests are marked as autostart all of them are started at once. The same is true when guests are started/resumed from the libvirt-guests init script. In my case it puts load on the system and starting 10 guests at once appears to be slower (time from boot to login prompt) than starting them one after the other. Attached is a small patch to sleep $BOOT_TIMEOUT seconds before starting the next guest. Version-Release number of selected component (if applicable): git as of today. How reproducible: Always Steps to Reproduce: 1. Create several KVM guests and let libvirt-guests script start them 2. 3. Actual results: All guests are started at once. It is not possible to start guests one after the other. Expected results: Additional info: Similar functionality exists when shutting down guests.