+++ 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.
Hi Zak, can you please provide reproducers for this issue? Or at least logs.
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.
(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
(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
Lon, any news with this one? Thanks, Michal