On Tue, Oct 28, 2014 at 11:14 AM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list