On Tue, Nov 21, 2006 at 09:20:06AM +0000, Ewan Mellor wrote:
> On Mon, Nov 20, 2006 at 08:23:24PM -0500, Graham, Simon wrote:
>
> > Well, I didn't expect this much discussion!!! I must admit I found it
> > hard to grok this code initially but I think the idea of exec'ing a
> > separate program is a good one to avoid the chance that xend can die
> > (especially since you don't currently seem to be able to restart xend
> > without rebooting Dom0).
>
> That's not true -- Xend ought to be restarting itself (it forks itself so that
> it has a monitor process) and even then "xend restart" ought to work. Are you
> having trouble with that?
>
> The one process that we can't restart at the moment is xenstored. Everything
> else should be fine.
While XenD itself can easily be restarted it does cause a few problems
if you have any HVM domains, or paravirt + blktap domains running. XenD
is the parent process for both qemu-dm and tapdisk helper processes. It
appears that these two are incapable of detecting shutdown of the guest
they are associated with themselves, and instead rely on XenD to tell
them when to exit / kill them. So the problem is, that if you restart
XenD these processes get re-parented to init, and then when you shutdown
the guest domain, the qemu-dm/tapdisk helpers stay around causing the
domain to linger in zombie state forever.
If we could figure out how to sort this, then XenD would be trivially
restartable without any ill effects.
> > Anyway - even if XendCheckpoint.py called xc_linux_save/restore
> > directly, you'd still have to deal with getting the output to the right
> > place since these APIs write their debug output directly to stderr so
> > I've got to believe you'd still fork a child that made the call and have
> > the parent slurp the contents of stderr and log them so the same issue
> > would exist...
>
> Yes, I think Daniel was proposing fixing all of that, too.
Yes, the formalized libxc error handling patches would make that unncessary
if the calls were made in-process. Of course I still need to write another
iteration of those patches based on latest round of feedback, so we can put
this issue off to a later date.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home