Bug 610208

Summary: Crashed domU sometimes leaves qemu-dm / xvnc processes
Product: Red Hat Enterprise Linux 5 Reporter: Lon Hohberger <lhh>
Component: xenAssignee: Xen Maintainance List <xen-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: low    
Version: 5.3CC: bburns, cchen, clalance, grimme, iannis, jmh, minovotn, mrezanin, nenad, rbinkhor, schlegel, sghosh, xen-maint, zbrown
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 479737 Environment:
Last Closed: 2011-04-04 07:43:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 514498    

Description Lon Hohberger 2010-07-01 18:39:43 UTC 
+++ This bug was initially created as a clone of Bug #479737 +++

 c. When RGmanager VMs crash, it sometimes leaves qemu-dm and Xvnc processes hanging around on other machines in a cluster.  This is bad because it seems to cause VM instability when the VM starts somewhere else.  The processes live on, but since you can't see them in virsh list or xm list, it's tough to spot.  usually the VMs end of up with corrupted /var or / partitions when this happens which (as you'll see from #4) is a pain.


((bunch of unrelated information deleted))

--- Additional comment from lhh on 2009-09-29 15:12:24 EDT ---

Actually, since we entirely use virsh and xm to manage VMs, item (c) is not very "fixable" without really digging in to things.

--- Additional comment from pmyers on 2009-10-21 22:21:32 EDT ---

I agree with comment #16 and #17 here.  This needs to be fixed in the virt tools themselves.  rgmanager is not causing vnc sessions and qemu-dm processes to be left around when the domU crashes.  cc'ing bburns from the virt team to look at this.  Since item c) is the only item left open in the original list of issues, and item c) is really a Xen issue I'm inclined to change the component to xen.

Also, in order to figure out item c) we need reproducers or logs from when this happens.  Without that there's not much we can do.

--- Additional comment from jdenemar on 2009-10-23 03:27:59 EDT ---

Yes, I agree leaving qemu-dm running is something which should be fixed in Xen. Not sure about Xvnc processes as they are not started by Xen. Anyway, as Perry already mentioned, we would need logs and ideally reproducers. And I think it would be a great idea to make a new BZ for this issue rather than using this one as it covers several issues and is full of irrelevant data.
Comment 1 Miroslav Rezanina 2010-07-02 06:41:24 UTC 
Hi Zak,
can you please provide reproducers for this issue? Or at least logs.
Comment 2 Zak Berrie 2010-07-02 19:20:44 UTC 
The original report on this was over a year ago so I may have a hard time getting logs from the time of report.  I'll see what I can get from the customer.
Comment 3 Michal Novotny 2010-07-08 12:35:50 UTC 
(In reply to comment #2)
> The original report on this was over a year ago so I may have a hard time
> getting logs from the time of report.  I'll see what I can get from the
> customer.    

Hi Zak,
steps to reproduce this would be appreciated. Does is still happen that crashed domU leaves the qemu-dm process? Since this bug was opened I guess it happened recently. Any steps to reproduce available?

Thanks,
Michal
Comment 4 Michal Novotny 2010-07-08 14:16:40 UTC 
(In reply to comment #3)
> (In reply to comment #2)
> > The original report on this was over a year ago so I may have a hard time
> > getting logs from the time of report.  I'll see what I can get from the
> > customer.    
> 
> Hi Zak,
> steps to reproduce this would be appreciated. Does is still happen that crashed
> domU leaves the qemu-dm process? Since this bug was opened I guess it happened
> recently. Any steps to reproduce available?
> 
> Thanks,
> Michal    

Just one clarification, the logs doesn't have to be from the time when it was reported. It can be any newer log from the incident if it happened but I'm afraid it won't help much but maybe qemu-dm.{PID}.log could have some information relevant to this one so please provide us qemu-dm.{PID}.log and xend.log once you/customer manage to reproduce it. Also, you're referring to the customer but I don't see any IT linked with this bug. Shouldn't there be one?

Michal
Comment 6 Michal Novotny 2011-03-02 11:47:36 UTC 
Lon, any news with this one?

Thanks,
Michal