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

[Conrad Meyer]

On Tue, Oct 28, 2014 at 11:14 AM, Daniel P. Berrange
<berrange at redhat.com> wrote:
> 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.

+1 from me (so long as the out-of-band hack isn't explicitly blocked).

Best,
Conrad