On Tue, Oct 28, 2014 at 06:01:51PM +0300, Roman Bogorodskiy wrote: > 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@xxxxxxxxxx> > > > --- > > > 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@xxxxxxxxxxx/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... Maybe it suffices to just say that libvirt does not officially support interactive bootloaders. Don't try to block any specific configurations. People can use the out-of-band hack if they really want to, but we make no promises about future compatibility or support of this hack. So if it breaks in a upgrade they get to keep both pieces. Then long term just focus on fully interactive BIOS running guestside. Regards, 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list