Bug 241303

When VMM is unable to open the console of the vm in question, then, only then,
the vm's qemu process starts consuming more cpu than usual (say from 1% CPU
utilisation it'd often jump to 10-20%, but not too much).

After that happens, VMM will never recover, forcing me to the forceful
termination of it. Weird.

Whether VMM is working or not, the individual vms themselves are quite unaware
of the VMM's problem & continue to function normally (tested over, say an SSH
session to the Linuxy/Unixy vms).

Of course, it'd be nice to have a reachable/working console to each vm, no
matter how many times VMM is restarted.

Looking at the Xen codebase, it appears they are missing a data corruption
bugfix in the VNC server which will (randomly) hit after a VNC client
disconnects. I'm almost certain you're hitting this, since the behaviour you
describe with high CPU load & hangs upon subsequent connects match the symptoms
of the bug.

Created attachment 155448 [details]
Fix handling of file descriptors on VNC client disconnect

This is the patch applied to upstream QEMU. Hopefully it will work with QEMU
0.8.0 without too much further work.

Sounds good. If I may request you to provide me the rpm version of the packages
involved, and if you do :-), I'm quite keen to have it tested.

(Fedora 7 test 4 system with up to date updates has qemu-0.9.0-2.fc7. Would the
above fix be applicable there also?)

Thanks for a quick response & analysis of the problem. I really appreciate that.

The 'qemu' RPM is not actually used by  Xen at all - Xen has forked the QEMU
code and maintains its own private copy. I'll be pushing out this fix in an
updated RPM asap.

Sorry I'm unable to understand whether the updates you are referring to are
going to really address my problem due to my own ignorance. Sorry if this is an
FAQ: I have only KVM based qemu vms (ie, only fully virtualised vms and no xen
paravirtualised) in the system; in my case, do you think the updates (xen/qemu
??) you are talking about are going to help?

$ rpm -qa|egrep -i 'xen|qemu|kvm|kernel|vnc|virt'
kernel-2.6.21-1.3189.fc7
kernel-headers-2.6.21-1.3189.fc7
kvm-24-1
libvirt-0.2.2-4.fc7
libvirt-python-0.2.2-4.fc7
python-virtinst-0.103.0-3.fc7
qemu-0.9.0-2.fc7
virt-manager-0.4.0-2.fc7
vnc-libs-4.1.2-16.fc7
vnc-server-4.1.2-16.fc7
xen-libs-3.1.0-0.rc7.1.fc7

Thanks

In VMM, I'm able to reproduce the problem only against the guest with ID 1, I
think. Or it's quite easy to reproduce against guest ID 1 & extremely hard
against others.

change QA contact

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp