[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [patch]Make xend to take care of dead qemu-dm process



Hi Ian,

I have some question now.
1.For each hvm guest there will be a separate qemu-dm process created,so
we need to track multi opened named pipes.If use blocked read,does that
mean I have to fork a new child in xend for each hvm guest when it was
created?

2.If I have to fork childs in xend, Could I kill the corresponding
domain in this child process directly?

thanks
xiaowei


On Thu, 2008-05-29 at 10:23 +0800, shawn wrote:
> Hi Ian,
> 
> Thanks for your explanation:)
> Imporving this patch
> 
> regards,
> xiaowei
> 
> On Wed, 2008-05-28 at 10:37 +0100, Ian Jackson wrote:
> > shawn writes ("Re: [Xen-devel] [patch]Make xend to take care of dead 
> > qemu-dm process"):
> > > Could I ask if there is any methodology mistakes to solve this problem?
> > > or need I keep improving this patch?
> > 
> > I made some suggestions in a recent pair of messages in the thread
> > `c/s 17731 portability issues'.  Did you not receive those messages ?
> > >From over here they appear to have been copied to you as the author of
> > the errant patch.
> > 
> > Anyway, let me repeat myself:
> > 
> > Certainly running ps in this way is not the right way to do it.
> > 
> > Since qemu-dm is started by xend, it is quite possible for xend to
> > have a better and more reliable arrangement for detecting termination
> > of the qemu-dm process.  No polling is needed (and thus failure
> > detection can be immediate).
> > 
> > I suggested a design involving a named pipe.  qemu-dm would be passed
> > the writing end across exec but just keep it, and not write anything
> > to it.  xend would keep the reading end, and when it becomes readable
> > would collect the qemu-dm exit status with waitpid (with W_NOHANG).
> > xend would then kill the domain and report the fact of termination and
> > also qemu-dm's exit status if available.
> > 
> > On restart, xend would attempt to open the fifo again with
> > O_RDONLY|O_NONBLOCK which would fail EWOUDLBLOCK if qemu-dm was no
> > longer running; if it was still running then termination can be
> > detected as above, although the exit status won't be recoverable.
> > 
> > Does this all make sense ?  I'd be happy to expand on it if you'd like
> > to ask questions.  We'll make sure to review your next submission
> > thoroughly.
> > 
> > Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.