On Tue, Oct 28, 2014 at 11:01 AM, Roman Bogorodskiy <bogorodskiy@xxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list