Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 610208 - Crashed domU sometimes leaves qemu-dm / xvnc processes
Crashed domU sometimes leaves qemu-dm / xvnc processes
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.3
x86_64 Linux
low Severity high
: rc
: ---
Assigned To: Xen Maintainance List
Virtualization Bugs
:
Depends On:
Blocks: 514498
  Show dependency treegraph
 
Reported: 2010-07-01 14:39 EDT by Lon Hohberger
Modified: 2016-04-26 11:19 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 479737
Environment:
Last Closed: 2011-04-04 03:43:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lon Hohberger 2010-07-01 14:39:43 EDT
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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 02:41:24 EDT
Hi Zak,
can you please provide reproducers for this issue? Or at least logs.
Comment 2 Zak Berrie 2010-07-02 15:20:44 EDT
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 08:35:50 EDT
(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 10:16:40 EDT
(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 06:47:36 EST
Lon, any news with this one?

Thanks,
Michal

Note You need to log in before you can comment on or make changes to this bug.