RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 695653 - [patch] Implement BOOT_TIMEOUT
Summary: [patch] Implement BOOT_TIMEOUT
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 6.2
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 695654 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-12 10:17 UTC by Alexander Todorov
Modified: 2011-12-06 11:05 UTC (History)
8 users (show)

Fixed In Version: libvirt-0.9.1-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 695654 (view as bug list)
Environment:
Last Closed: 2011-12-06 11:05:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch to implement BOOT_TIMEOUT functionality (1.48 KB, patch)
2011-04-12 10:17 UTC, Alexander Todorov
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1513 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-12-06 01:23:30 UTC

Description Alexander Todorov 2011-04-12 10:17:18 UTC
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.

Comment 1 Eric Blake 2011-04-12 13:54:39 UTC
Please post this patch to libvir-list, so that it can get reviewed for inclusion into the upstream libvirt.

Comment 2 Alexander Todorov 2011-04-13 08:17:19 UTC
Send to the list.

Comment 4 Dave Allan 2011-04-14 20:03:57 UTC
Initial upstream submit and feedback at:

https://www.redhat.com/archives/libvir-list/2011-April/msg00629.html

Comment 5 Dave Allan 2011-04-14 20:07:43 UTC
*** Bug 695654 has been marked as a duplicate of this bug. ***

Comment 6 Jiri Denemark 2011-04-20 13:37:35 UTC
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.

Comment 7 zhanghaiyan 2011-05-25 09:43:33 UTC
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

Comment 9 Min Zhan 2011-07-18 07:19:46 UTC
Move to Verified according to Comment #7

Comment 10 errata-xmlrpc 2011-12-06 11:05:00 UTC
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


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