[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] xm-test domain creation delay
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.
IBM Linux Technology Center
Open Hypervisor Team
Xen-devel mailing list