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: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xm-test domain creation delay
From: Dan Smith <danms@xxxxxxxxxx>
Date: Mon, 14 Nov 2005 08:00:06 -0800
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 14 Nov 2005 16:00:12 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20051114154823.GD16045@xxxxxxxxxxxxxxxxxxxxxx> (Ewan Mellor's message of "Mon, 14 Nov 2005 15:48:23 +0000")
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
EM> Here's an idea for xm-test.  Instead of waiting a full 20 seconds
EM> for the guest domain to come up, we could instead write to the
EM> store from inside the guest.

Yes, we definitely need to eliminate the 20-second delay for each
DomU.  The reason we do this is that when xm-test was being developed,
the block driver conversion to xenbus was happening, and the DomUs
were taking a long time to boot, especially if no block devices were
attached.  I was planning to lower this timeout, but it would
definitely be better if we had some sort of notification.

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.

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.

Thoughts?

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@xxxxxxxxxx


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