WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Dan Smith <danms@xxxxxxxxxx>
Subject: Re: [Xen-devel] xm-test domain creation delay
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Mon, 14 Nov 2005 16:10:25 +0000
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 14 Nov 2005 16:10:44 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <87fypzi5ix.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20051114154823.GD16045@xxxxxxxxxxxxxxxxxxxxxx> <87fypzi5ix.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
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