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