Re: [Xen-devel] [PATCH,RFC]: Introduce libxl_domain_create()

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH,RFC]: Introduce 
libxl_domain_create()"):
> On Tue, 2010-12-21 at 11:33 +0000, Ian Jackson wrote:
> > Yes.  The primary console for an HVM guest is not a PV console, but
> > the guest's emulated serial port provided by qemu.  So to connect to
> > it you need qemu running.
> 
> Why is that?
> 
> In the PV case the xenconsole client is quite happy to sit and wait (on
> a xenstore watch) for the console entries to be created in xenstore. Why
> can the qemu case not do the same?

TBH I think this is a bug in the xenconsole client, because it means
that the xenconsole client has an arbitrary timeout when it ought to
be started at the point when we know that the console is there.

But I think you are right and this isn't the reason why it's done like
that at the moment.

I vaguely remember some complication with the bootloader.  Perhaps the
problem was that we can't start the console client until the
bootloader has finished using our controlling terminal ?

It seems to me that the right approach is
 (a) the domain creation function should call back to the application
     to say "your domain's console is ready now and you can connect to
     it if you like"
 (b) the bootloader's console should be plumbed explicitly rather
     than simply relying on inheriting a suitable terminal from the
     library's caller.

Without (b), doing xapi or libvirt on top of libxl is going to be
impossible.

TBH some of the console plumbing is pretty horrid and needs a
redesign.  For example, why can't you connect to the same domain more
than once ?  (Ans: because xenconsoled uses ptys for talking to
xenconsole!!)  Why can't you automatically log the guest's serial
console ?  (Ans: because that's done with completely separate code in
qemu which doesn't know how to do more than speak to a particular
tty.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel