| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 0/3] continuable destroy domain:MakeXEN_DOMCTL_de
Xend probably has a critical resource (either a lock or a thread) that gets tied up in the shutdown. So it can’t do anything else significant while the shutdown is in progress. The solution will be to add some multi-threading (perhaps just as simple as spawning a thread to handle long operations like domain destruction or coredumps). Someone already posted a (rather complicated) patch to spawn a thread to deal with domain coredumps. It hasn’t been checked in as there were arguments over the approach (it spawned an external C program, whereas it should be quite possible to spawn the thread and do the coredump without any exec of an external program).
Thus this is something of a current design limitation of xend rather than an outright bug. As such it is unlikely to get fixed anytime soon unless someone wants to pick it up as a project?
-- Keir
On 9/10/07 16:49, "Szymanski, Lukasz K" <Lukasz.Szymanski@xxxxxxxxxx> wrote:
If I do not use xm top while the vm is shutting down, there are fewer or no problem with system responsiveness.
- If I run xm list (or xm info or xm dmesg) during a shutdown, then nothing gets listed, but I have control over all the terminals and I can ctrl-C my way out of the xm command.
- If I do a shutdown and a non xm command such as ping, I can ping another domain and I have no responsive problems at all with zero packets lost.
It appears that the error is in the combination of xm commands and shutdown. Running xm top with shutdown shows this behavior the most.
At this point I am trying to find out exactly when things get stuck for xm top and shutdown.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home