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

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: > > > <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.