All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: "Graham, Simon" <Simon.Graham@stratus.com>
Cc: xen-devel@lists.xensource.com, Ewan Mellor <ewan@xensource.com>
Subject: Re: Trivial patch to fix logging level output by XendCheckpoint.py
Date: Tue, 21 Nov 2006 15:04:04 +0000	[thread overview]
Message-ID: <20061121150404.GE1951@redhat.com> (raw)
In-Reply-To: <342BAC0A5467384983B586A6B0B3767104190414@EXNA.corp.stratus.com>

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

  reply	other threads:[~2006-11-21 15:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-21 14:58 Trivial patch to fix logging level output by XendCheckpoint.py Graham, Simon
2006-11-21 15:04 ` Daniel P. Berrange [this message]
2006-11-21 15:05 ` Ewan Mellor
  -- strict thread matches above, loose matches on Subject: below --
2006-11-21  1:23 Graham, Simon
2006-11-21  9:20 ` Ewan Mellor
2006-11-21 12:29   ` Daniel P. Berrange
2006-11-20 21:34 Graham, Simon
2006-11-20 21:56 ` Daniel P. Berrange
2006-11-20 22:34   ` Anthony Liguori
2006-11-20 22:43     ` Daniel P. Berrange
2006-11-20 22:40   ` Ewan Mellor
2006-11-20 22:53     ` John Levon
2006-11-21 10:19 ` Ewan Mellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061121150404.GE1951@redhat.com \
    --to=berrange@redhat.com \
    --cc=Simon.Graham@stratus.com \
    --cc=ewan@xensource.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.