Re: [libvirt] [PATCHv5 1/6] bhyve: Support /domain/bootloader configuration for non-FreeBSD guests.

Daniel P. Berrange wrote: > On Mon, Oct 27, 2014 at 10:37:36AM -0400, Conrad Meyer wrote: > > We still default to bhyveloader(1) if no explicit bootloader > > configuration is supplied in the domain. > > > > If the /domain/bootloader looks like grub-bhyve and the user doesn't > > supply /domain/bootloader_args, we make an intelligent guess and try > > chainloading the first partition on the disk (or a CD if one exists, > > under the assumption that for a VM a CD is likely an install source). > > > > Caveat: Assumes the HDD boots from the msdos1 partition. I think this is > > a pretty reasonable assumption for a VM. (DrvBhyve with Bhyveload > > already assumes that the first disk should be booted.) > > > > I've tested both HDD and CD boot and they seem to work. > > > > Sponsored by: EMC / Isilon storage division > > > > Signed-off-by: Conrad Meyer <conrad.meyer(a)isilon.com&gt; > > --- > > docs/drvbhyve.html.in | 94 ++++++++++++++++++++- > > docs/formatdomain.html.in | 4 +- > > src/bhyve/bhyve_command.c | 202 +++++++++++++++++++++++++++++++++++++++++----- > > src/bhyve/bhyve_command.h | 5 +- > > src/bhyve/bhyve_domain.c | 5 ++ > > src/bhyve/bhyve_domain.h | 1 + > > src/bhyve/bhyve_driver.c | 2 +- > > src/bhyve/bhyve_process.c | 13 ++- > > 8 files changed, 298 insertions(+), 28 deletions(-) > > > > diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in > > index 39afdf5..ee1317e 100644 > > --- a/docs/drvbhyve.html.in > > +++ b/docs/drvbhyve.html.in > > @@ -37,8 +37,7 @@ bhyve+ssh://root@example.com/system (remote access, SSH tunnelled) > > <h3>Example config</h3> > > <p> > > The bhyve driver in libvirt is in its early stage and under active development. So it supports > > -only limited number of features bhyve provides. All the supported features could be found > > -in this sample domain XML. > > +only limited number of features bhyve provides. > > </p> > > > > <p> > > @@ -48,10 +47,21 @@ disk device were supported per-domain. However, > > up to 31 PCI devices. > > </p> > > > > +<p> > > +Note: the Bhyve driver in libvirt will boot whichever device is first. If you > > +want to install from CD, put the CD device first. If not, put the root HDD > > +first. > > +</p> > > FYI, the libvirt XML allows for a <boot order='NNN'/> element to be > included by the user in any <disk>, <interface> or <hostdev> element. > > This is considered to obsolete the <boot dev="cdrom|disk|network"/> > config we originally used, so that we can get fine grained control > over device boot order, independant of XML format. > > Your patch is fine as it is, i just mention this as something you > might consider adding support for in later work. > > > > <h2><a name="usage">Guest usage / management</a></h2> > > > > @@ -119,6 +177,14 @@ to let a guest boot or start a guest using:</p> > > > > <pre>start --console domname</pre> > > > > +<p><b>NB:</b> An interactive bootloader will keep the domain from starting (and > > +thus <code>virsh console</code> or <code>start --console</code>) until the > > +console is opened by a client. To select a boot option and allow the domain to > > +finish starting, one must use an alternative terminal client to connect to the > > +null modem device. One example is:</p> > > Can you clarify what you mean by this. It seems like this is saying that > the 'virDomainCreate' API (virsh start GUEST command) will not return > controll to the caller until you've interacted with the bootloader. > > If correct, I don't think this is a very satisfactory solution. There > should not be any requirement to interact with the guest domain until > after the virDomainCreate API call completes successfully. If succesfully > booting requires that you go via an out-of-band channel to interact with > the bootloader that's even more of a problem. > > Because libvirt has an RPC based mechanism for API access, we need to > always bear in mind that the application/user talking to libvirt drivers > is either local but unprivileged, or even entirely remote from the hypervisor > node. The libvirt built-in console tunnels over our RPC channel to provide > apps access. > > So if my understanding is correct, this limitation you describe is going > to prevent use of this kind of setup from most apps using libvirt. > > We need to at least come up with a plan of how we'd address this problem > in the medium term. That is my concern as well. :( I'm wondering if we probably should just state that we're currently support VMs that don't need any interactive interactions at the boot loader step? Vaporware or not, I'm sure that solving it on the Bhyve sise (e.g. either get UEFI support or at least pass loader options to it so it could run it itself) is a much better solution than development of the workarounds in libvirt...