6:37 a.m.
Awhile back a bug was filed against libvirt about the inability to
completely exclude a disk from the boot order:
https://bugzilla.redhat.com/show_bug.cgi?id=888635
In short, you can't have a domain that used PXE to boot, but also has an
un-bootable disk device *even if that disk isn't listed in the boot
order*, because if PXE times out (e.g. due to the bridge forwarding
delay), the BIOS will move on to the next target, which will be the
unbootable disk device (again - even though it wasn't given a boot
order), and get stuck at a "/BOOT DISK FAILURE, PRESS ANY KEY" message
/until a user intervenes.
It was obviously beyond the ability of libvirt to fix this (although it
can be worked around by creating a very small disk image with a
bootloader that merely instructs the system to reboot, and placing
*that* disk in the boot order just after the PXE device), so the BZ was
closed as CANTFIX.
A couple days ago I noticed that Amos Kong had later actually fixed this
problem in seabios and qemu:
https://bugzilla.redhat.com/show_bug.cgi?id=888633
https://bugzilla.redhat.com/show_bug.cgi?id=903204
Existing behavior is preserved though, and the new behavior only comes
about if "-boot strict" is specified on the qemu commandline.
It definitely seems desirable to have this ability in libvirt, but I'm
almost of the opinion that this should *always* be the behavior (if you
want all devices to be in the boot order, you can just give all of them
(or none of them, if you're feeling adventurous) a boot order ranking).
But I thought it would be prudent to ask opinions about that before
making any patch.
So what are the opinions? Should the "if any devices are given a boot
order, only attempt to boot from devices that have a boot order
specified" behavior just be the default (and only) behavior when
qemu/seabios supports it? (this would imply that the old behavior is
just a bug)? Or do we need to make it configurable? If it needs to be
configurable, the boot-related xml seems to be a bit unorganized (a flat
list of elements with mostly a single attribute for each), but I suppose
this could be added as a new attribute to the <bios> element...
7:21 a.m.
On Wed, Nov 27, 2013 at 14:37:02 +0200, Laine Stump wrote:
Awhile back a bug was filed against libvirt about the inability to
completely exclude a disk from the boot order:
https://bugzilla.redhat.com/show_bug.cgi?id=888635
In short, you can't have a domain that used PXE to boot, but also has an
un-bootable disk device *even if that disk isn't listed in the boot
order*, because if PXE times out (e.g. due to the bridge forwarding
delay), the BIOS will move on to the next target, which will be the
unbootable disk device (again - even though it wasn't given a boot
order), and get stuck at a "/BOOT DISK FAILURE, PRESS ANY KEY" message
/until a user intervenes.
It was obviously beyond the ability of libvirt to fix this (although it
can be worked around by creating a very small disk image with a
bootloader that merely instructs the system to reboot, and placing
*that* disk in the boot order just after the PXE device), so the BZ was
closed as CANTFIX.
A couple days ago I noticed that Amos Kong had later actually fixed this
problem in seabios and qemu:
https://bugzilla.redhat.com/show_bug.cgi?id=888633
https://bugzilla.redhat.com/show_bug.cgi?id=903204
Existing behavior is preserved though, and the new behavior only comes
about if "-boot strict" is specified on the qemu commandline.
It definitely seems desirable to have this ability in libvirt, but I'm
almost of the opinion that this should *always* be the behavior (if you
want all devices to be in the boot order, you can just give all of them
(or none of them, if you're feeling adventurous) a boot order ranking).
But I thought it would be prudent to ask opinions about that before
making any patch.
So what are the opinions? Should the "if any devices are given a boot
order, only attempt to boot from devices that have a boot order
specified" behavior just be the default (and only) behavior when
qemu/seabios supports it? (this would imply that the old behavior is
just a bug)? Or do we need to make it configurable?
I would consider the old behavior as a bug and just use -boot strict
whenever we can.
Jirka
7:24 a.m.
On Wed, Nov 27, 2013 at 02:37:02PM +0200, Laine Stump wrote:
Awhile back a bug was filed against libvirt about the inability to
completely exclude a disk from the boot order:
https://bugzilla.redhat.com/show_bug.cgi?id=888635
In short, you can't have a domain that used PXE to boot, but also has an
un-bootable disk device *even if that disk isn't listed in the boot
order*, because if PXE times out (e.g. due to the bridge forwarding
delay), the BIOS will move on to the next target, which will be the
unbootable disk device (again - even though it wasn't given a boot
order), and get stuck at a "/BOOT DISK FAILURE, PRESS ANY KEY" message
/until a user intervenes.
It was obviously beyond the ability of libvirt to fix this (although it
can be worked around by creating a very small disk image with a
bootloader that merely instructs the system to reboot, and placing
*that* disk in the boot order just after the PXE device), so the BZ was
closed as CANTFIX.
I'm fairly sure that the current behaviour we have is a regression vs
the original libvirt QEMU driver prior to use of seabios. IOW, I think
we should unconditionally be enabling strict=on to fix the flaw.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
5:56 p.m.
On Wed, Nov 27, 2013 at 02:37:02PM +0200, Laine Stump wrote:
Awhile back a bug was filed against libvirt about the inability to
completely
exclude a disk from the boot order:
https://bugzilla.redhat.com/show_bug.cgi?id=888635
In short, you can't have a domain that used PXE to boot, but also has an
un-bootable disk device *even if that disk isn't listed in the boot order*,
because if PXE times out (e.g. due to the bridge forwarding delay), the BIOS
will move on to the next target, which will be the unbootable disk device
(again - even though it wasn't given a boot order), and get stuck at a "BOOT
DISK FAILURE, PRESS ANY KEY" message until a user intervenes.
It was obviously beyond the ability of libvirt to fix this (although
it can be
worked around by creating a very small disk image with a bootloader that merely
instructs the system to reboot, and placing *that* disk in the boot order just
after the PXE device), so the BZ was closed as CANTFIX.
We have a reboot-timeout boot parameter to reboot guest if not found
bootable device.
| commit ac05f3492421caeb05809ffa02c6198ede179e43
| Author: Amos Kong <akong(a)redhat.com>
| Date: Fri Sep 7 11:11:03 2012 +0800
|
| add a boot parameter to set reboot timeout
|
| Added an option to let qemu transfer a configuration file to bios,
| "etc/boot-fail-wait", which could be specified by command
| -boot reboot-timeout=T
| T have a max value of 0xffff, unit is ms.
|
| 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.
|
| This feature need the new seabios's support.
|
| Seabios pulls the value from the fwcfg "file" interface, this
| interface is used because SeaBIOS needs a reliable way of
| obtaining a name, value size, and value. It in no way requires
| that there be a real file on the user's host machine.
|
| Signed-off-by: Amos Kong <akong(a)redhat.com>
| Signed-off-by: Anthony Liguori <aliguori(a)us.ibm.com>
|
A couple days ago I noticed that Amos Kong had later actually fixed
this
problem in seabios and qemu:
https://bugzilla.redhat.com/show_bug.cgi?id=888633
https://bugzilla.redhat.com/show_bug.cgi?id=903204
Existing behavior is preserved though, and the new behavior only comes about if
"-boot strict" is specified on the qemu commandline.
It definitely seems desirable to have this ability in libvirt, but
I'm almost
of the opinion that this should *always* be the behavior (if you want all
devices to be in the boot order, you can just give all of them (or none of
them, if you're feeling adventurous) a boot order ranking).
We leave the default as off just for compatibility with old qemu.
For libvirt code, you can always use "strict=on"
But I thought it
would be prudent to ask opinions about that before making any patch.
So what are the opinions? Should the "if any devices are given a boot order,
only attempt to boot from devices that have a boot order specified" behavior
just be the default (and only) behavior when qemu/seabios supports it? (this
would imply that the old behavior is just a bug)? Or do we need to make it
configurable? If it needs to be configurable, the boot-related xml seems to be
a bit unorganized (a flat list of elements with mostly a single attribute for
each), but I suppose this could be added as a new attribute to the <bios>
element...
--
Amos.
8:31 a.m.
On 11/28/2013 01:56 AM, Amos Kong wrote:
On Wed, Nov 27, 2013 at 02:37:02PM +0200, Laine Stump wrote:
> Awhile back a bug was filed against libvirt about the inability to completely
> exclude a disk from the boot order:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=888635
>
> In short, you can't have a domain that used PXE to boot, but also has an
> un-bootable disk device *even if that disk isn't listed in the boot order*,
> because if PXE times out (e.g. due to the bridge forwarding delay), the BIOS
> will move on to the next target, which will be the unbootable disk device
> (again - even though it wasn't given a boot order), and get stuck at a
"BOOT
> DISK FAILURE, PRESS ANY KEY" message until a user intervenes.
> It was obviously beyond the ability of libvirt to fix this (although it can be
> worked around by creating a very small disk image with a bootloader that merely
> instructs the system to reboot, and placing *that* disk in the boot order just
> after the PXE device), so the BZ was closed as CANTFIX.
We have a reboot-timeout boot parameter to reboot guest if not found
bootable device.
Yes. libvirt supports that parameter. The problem was that the disk was
"bootable", but just happened to boot into an "operating system"
whose
only function was to print out
BOOT DISK FAILURE, PRESS ANY KEY
then wait indefinitely for a key to be pressed :-)
> A couple days ago I noticed that Amos Kong had later actually
fixed this
> problem in seabios and qemu:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=888633
> https://bugzilla.redhat.com/show_bug.cgi?id=903204
>
> Existing behavior is preserved though, and the new behavior only comes about if
> "-boot strict" is specified on the qemu commandline.
> It definitely seems desirable to have this ability in libvirt, but I'm almost
> of the opinion that this should *always* be the behavior (if you want all
> devices to be in the boot order, you can just give all of them (or none of
> them, if you're feeling adventurous) a boot order ranking).
We leave the default as off just for compatibility with old qemu.
For libvirt code, you can always use "strict=on"
Right. The fact that it's configurable in qemu raises the question of
whether there may be legitimate cases for libvirt where someone would
expect/demand the old behavior, and the new behavior would cause
breakage of existing setups. If there are, I don't want to prevent them
by making it unconfigurable, but if there aren't, I don't want to
clutter up config with yet another unnecessary knob.
4016
days inactive
4017
days old
4 comments
4 participants
participants (4)
-
Amos Kong -
Daniel P. Berrange -
Jiri Denemark -
Laine Stump