This bug has been copied from bug #593120 and has been proposed to be backported to 5.5 z-stream (EUS).
Fix built into libvirt-0.6.3-33.el5_5.2
When I am trying to verify the bug, I always can not reproduce this bug. libvirt-0.6.3-33.el5 xen-3.0.3-114.el5 2.6.18-194.el5xen 1. Following the steps of BZ #593120, here I created 6 guests which are in an endless reboot/crash cycle. 2. Run "virsh list" and "xm list" to check the output of this two command At my side, the output is always the same, so I can not reproduce this bug. I also used the following shell script given by Jiri Denemark to watch the output discrepancy. while true; do xm list | awk '{print $2;}' | while read; do [[ "${REPLY//-/}" -gt 0 ]] && echo $REPLY; done | sort -n >/tmp/xm; virsh list | awk '{print $1;}' | while read; do [[ "${REPLY//-/}" -gt 0 ]] && echo $REPLY; done | sort -n > /tmp/virsh; join -j 1 -v 1 -e \* /tmp/xm /tmp/virsh; for i in `seq 5`; do printf =; sleep 1; done; echo; done 2>/dev/null (once start seeing numbers instead of just '=' signs, you reproduced the issue) Although I saw some numbers instead of "=" signs sometimes, after I updated the libvirt to libvirt-0.6.3-33.el5_5.3, I still can see some number sometimes. That seems more like a result of virsh list and xm list not being run at the same time... the domains might have just been rebooted between xm list and virsh list. So I need some better steps to reproduce this bug, and verify it.
(In reply to comment #5) > So I need some better steps to reproduce this bug, and verify it. Sorry, I can't give you any better steps since I was able to reproduce it with the steps provided by the reporter. Perhaps the reporter is aware of better test scenario. Or could we actually use the reporter for testing the package when QA is not able to reproduce the issue?
It usually takes a while for the problem to actually manifest itself (at least it did on the system where I originally reproduced the issue). I've started my reproducer again and once the difference occurs I'll update to the package from comment #3 and verify the fix and/or give access to the reproducer to QE.
Thanks for Scott Mayhew 's great help. I finally find the key point to reproduce this bug. Must turn on dump switch in /etc/xen/xend-config.sxp Verified this bug with libvirt-0.6.3-33.el5_5.3 on RHEL5u5 Server x86_64 Xen, RHEL5u5 Client i386 and RHEL5u5 Server ia64, and PASSED. 1. Turn on dump switch in /etc/xen/xend-config.sxp, and restart xend service. (enable-dump yes) 2. Follow the steps in #593120. 3. Run the following command. # virsh list; xm list Id Name State ---------------------------------- 0 Domain-0 running 2 it493693a idle Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 5826 4 r----- 126.9 it493693a 2 511 1 -b---- 11.8 it493693b 24 512 1 -b---- 0.2 it493693c 25 512 1 -b---- 0.2 it493693d 26 512 1 -b---- 0.2 4. Discrepancy between xm and virsh output is seen. 5. Upgrade libvirt version to libvirt-0.6.3-33.el5_5.3 6. Run the following command: # virsh list; xm list Id Name State ---------------------------------- 0 Domain-0 running 2 it493693a idle 27 it493693b idle 28 it493693c idle 29 it493693d idle Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 5826 4 r----- 141.2 it493693a 2 511 1 -b---- 11.8 it493693b 27 512 1 -b---- 0.2 it493693c 28 512 1 -b---- 0.2 it493693d 29 512 1 -b---- 0.2 Discrepancy disappeared. So this bug is fixed.
Now the reproduce steps are found, so I clear needinfo flag.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0615.html