Bug 854191 - Add a new boot parameter to set the delay time before rebooting
Summary: Add a new boot parameter to set the delay time before rebooting
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Amos Kong
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 855237
TreeView+ depends on / blocked
 
Reported: 2012-09-04 10:00 UTC by Amos Kong
Modified: 2015-05-25 00:06 UTC (History)
13 users (show)

Fixed In Version: qemu-kvm-0.12.1.2-2.320.el6
Doc Type: Bug Fix
Doc Text:
Cause: Customer requests to reboot guest if no bootable device found. Seabios will output an error message, wait for 60 seconds by default and reboot guest. But QEMU user could not control the delay time. Consequence: Need a qemu boot parameter to configure the delay time, user can also disable the reboot. Fix: Added an option ("-boot reboot-timeout=T") to let qemu transfer a configuration file ("etc/boot-fail-wait") to seabios. Result: User can assign the delay time by "-boot reboot-timeout=T", T have a max value of 0xffff, unit is ms. If reboot-timeout is '-1', guest will not reboot, qemu passes '-1' to seabios by default.
Clone Of:
: 855237 (view as bug list)
Environment:
Last Closed: 2013-02-21 07:39:21 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0527 0 normal SHIPPED_LIVE qemu-kvm bug fix and enhancement update 2013-02-20 21:51:08 UTC

Description Amos Kong 2012-09-04 10:00:22 UTC
Description of problem:

There is a bug [1] (VM will reboot if no boot failed).

As said in [2], we need to add a new boot parameter and put it into romfile for seabios to use, it's used to configure the delay time.

This work should start on upstream.

[1] Bug 831273 - RFE: reboot VM if no bootable device found
[2] https://bugzilla.redhat.com/show_bug.cgi?id=831273#c18

Comment 1 Amos Kong 2012-09-07 03:15:00 UTC
patch posted to upstream: http://patchwork.ozlabs.org/patch/182306/

example:
 -boot reboot-timeout=10000

With this option, guest will wait for a given time if not find
bootabled device, then reboot. If reboot-timeout is '-1', guest
will not reboot, qemu passes '-1' to bios by default.

Comment 2 Amos Kong 2012-09-07 04:33:32 UTC
Hi Eric,

If customer wants to use this 'feature'[1], do we need to change libvirt/virt-manager/etc to use this qemu parameter?


[1] Bug 831273 - RFE: reboot VM if no bootable device found

Thanks, Amos

Comment 3 Eric Blake 2012-09-07 04:41:58 UTC
(In reply to comment #2)
> Hi Eric,
> 
> If customer wants to use this 'feature'[1], do we need to change
> libvirt/virt-manager/etc to use this qemu parameter?

Yes; libvirt probably needs to enhance XML to support this; I cloned bug 855237 to track it.  (You can use the unsupported <qemu:commandline> XML to trigger it in the meantime while waiting for official libvirt support.)

Comment 11 FuXiangChun 2012-10-22 05:04:37 UTC
verify this issue with qemu-kvm-0.12.1.2-2.329 and seabios-0.6.1.2-25

testing three scenarios:
1. <=1 seconds
boot guest with -boot reboot-timeout=1000
 No boottable device. Retrying in (0)1 seconds.

2. >65seconds
boot guest with -boot reboot-timeout=1000000
 No boottable device. Retrying in 65 seconds.

3. default value
boot guest with -boot reboot-timeout=-1
  guest not reboot,and always show "No bootable device.

since qemu max support reboot-timeout effective value is 65 second(work as design). so base on this result above,  this bug is fixed.

Comment 14 errata-xmlrpc 2013-02-21 07:39:21 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-2013-0527.html


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