Re: [Xen-devel] xm-test domain creation delay

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Mon, Nov 14, 2005 at 08:00:06AM -0800, Dan Smith wrote:

> EM> The easiest way to do this would be with the command line tools
> EM> xenstore-read and xenstore-write.  If you use these tools without
> EM> the -s option, this should mean that they write using the domain's
> EM> implicit root, so if you don't use a path with a / at the front,
> EM> then the path will be unique per-domain.
> 
> This is not quite as easy as it sounds.  In order to simply copy the
> user's xenstore-write binary into the ramdisk, we would need to also
> copy several of their libraries like libc and libxenctrl.  We could
> recompile a static version of xenstore-write to go into the ramdisk,
> which may work.

Well it would be better if we could compile and link against the version of
libc in the ramdisk!  That would be a different version of xenstore-write to
the one that we compile for the user of course, which might be a pain to do,
but that's the right way to do it.  How do all the other applications in the
ramdisk get compiled now?

> EM> xm-test/booted=1 or something, and then the xm-test application
> EM> could register a watch for that path
> 
> So, I wonder if this kind of functionality would be useful outside the
> realm of xm-test?  Can anyone think of a reason why we might want to
> have this be built-in to the DomU kernel or something?
> 
> If not, I think the best (and easiest) way to solve the immediate
> problem in xm-test is to use the console as a way to poll the status
> of the DomU.  We can eliminate the explicit 20 second wait time, and
> instead have the console library make multiple attempts to attach,
> with a timeout of it fails for too long.  This would give us a much
> quicker DomU boot time, without requiring anything else to go into the
> initial ramdisk.  I'm working on a patch for this right now.

Is it sufficient to say that once you can connect the console, then the guest
is ready for commands?  That wouldn't be the case for a "real" guest, of
course, but if that's OK for xm-test (or close enough that we only need a 1
second timeout or something) then that sounds like a better idea.

Ewan.

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