RE: [Xen-devel] Trivial patch to fix logging level output by XendCheckpoint.py

["Graham, Simon" <Simon.Graham@xxxxxxxxxxx>]

> > > 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.
>

Yes we have had problems with this (in 3.0.2) -- however, we test this
with /etc/init.d/xend stop/start which will, I think, restart xenstored
as well, so I guess this still does not work. I will look into modifying
the test so it kills the main xend process instead to more accurately
test fault insertion in xend.

> 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.
> 

Ah - OK, well, we aren't testing HVM guests yet but we will be;
hopefully one of us can figure out how to solve this issue.

Simon

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