[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] xm-test domain creation delay
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.
Xen-devel mailing list