[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Trivial patch to fix logging level output by XendCheckpoint.py
On Tue, Nov 21, 2006 at 09:58:33AM -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. > > > > 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. The init script doesn't stop or start xenstored itself. The init script merely starts up XenD. XenD then checks to see if xenstored is already running, and if not starts it. When you do 'service xend stop' to shutdown XenD it will leave xenstored running. > > 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. This isn't only an issue with HVM - the tapdisk process is used by paravirt guests when blktap is used for file backed virtual disks. 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |