qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] [Qemu PATCH v2] add a boot option to do stric


From: Gleb Natapov
Subject: Re: [Qemu-devel] [libvirt] [Qemu PATCH v2] add a boot option to do strict boot
Date: Wed, 9 Jan 2013 19:46:35 +0200

On Wed, Jan 09, 2013 at 12:28:57PM -0500, Laine Stump wrote:
> On 01/09/2013 10:22 AM, Daniel P. Berrange wrote:
> > On Wed, Jan 09, 2013 at 08:14:07AM -0700, Eric Blake wrote:
> >> On 01/09/2013 01:39 AM, Amos Kong wrote:
> >>> Current seabios will try to boot from selected devices first,
> >>> if they are all failed, seabios will also try to boot from
> >>> un-selected devices.
> >>>
> >>> We need to make it configurable. I already posted a seabios
> >>> patch to add a new device type to halt booting. Qemu can add
> >>> "HALT" at the end of bootindex string, then seabios will halt
> >>> booting after trying to boot from selected devices.
> >>>
> >>> This option only effects when boot priority is changed by
> >>> bootindex options, the old style(-boot order=..) will still
> >>> try to boot from un-selected devices.
> >>>
> >>> v2: add HALT entry in get_boot_devices_list()
> >>>     define boot_strict to bool
> >>>
> >>> Signed-off-by: Amos Kong <address@hidden>
> >>> ---
> >> Libvirt will need to expose an attribute that lets the user control
> >> whether to use this new option; how do we probe via QMP whether the new
> >> -boot strict=on command-line option is available?
> > While libvirt should make use of this, we don't need to
> > expose it in the XML. This new behaviour is what we wanted
> > to have all along, so we should just enable it.
> 
> I agree that this is the way it *should* always work, but apparently
> there are people who depend on the old behavior, so just doing a blanket
> switch to the new behavior could lead to setups that no longer work
> "properly" after an upgrade, which unfortunately means that existing
> functionality needs to be maintained, and "correct" functionality must
> be triggered by a config switch (maybe Gleb can expand on the use cases
> that require this if more details are needed, as it's him I heard this from)

It is common to configure PXE boot as highest prio for easy re-imaging,
Usually boot from PXE fails and other bootable device is used instead,
but if re-installation is needed it is as easy as configuring PXE server
and rebooting the machine. With current behaviour it is enough to boost
PXE priority, if we will change it setups that didn't explicitly specify
all devices' priorities will stop working. The rule is easy: if exist
command line that will work differently before and after the change you
probably break someones setup with your patch.

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]