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

[Conrad Meyer]

On Tue, Oct 28, 2014 at 11:01 AM, Roman Bogorodskiy
<bogorodskiy at gmail.com> 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?

Sure.

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

Yes. I can draft a patch for bhyve to run the loader itself, but I
fear they might reject it due to "UEFI/BIOS support is coming."
Anyway, I think that's a bit orthogonal to this change. We already
block / fall over in the same way if bhyveload pauses and waits for
user input.

Thanks,
Conrad