[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH,RFC]: Introduce libxl_domain_create()
On Tue, 2010-12-21 at 14:07 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH,RFC]: Introduce
> > 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 ?
The opposite -- the bootloader interacts with the user via xenconsole.
> 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
(b) is already done and has been since Tim first plumbed the bootloader
> 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
Xen-devel mailing list