Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
it report error info while check the guest status with the libvirt-python script
when the guest os happens kernel panic
Version-Release number of selected component (if applicable):
libvirt-1.1.1-2.el7.x86_64
kernel-3.10.0-4.el7.x86_64
qemu-kvm-1.5.2-2.el7.x86_64
How reproducible:
100%
Steps
1.Prepare a guest with the following xml
#virsh dumpxml rhel7
--
<on_crash>coredump-destroy</on_crash>
--
2.In terminal 1 running the following command
#python /usr/share/doc/libvirt-python-1.1.1/events-python/event-test.py qemu:///system
3.Start the guest in terminal 2, then, login the guest and run the following command in the guest while the guest start completely
#sync
# printf '%b' '\x01' | dd of=/dev/port seek=$((16#505)) bs=1 count=1
4.Check the guest's relate info in host
<1>In terminal 1 ,i didn't see the crashd event in the domain event handler,it just report the following error.
# python /usr/share/doc/libvirt-python-1.1.1/events-python/event-test.py qemu:///system
Using uri:qemu:///system
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3854, in _dispatchDomainEventLifecycleCallback
cb(self, virDomain(self, _obj=dom), event, detail, opaque)
File "/usr/share/doc/libvirt-python-1.1.1/events-python/event-test.py", line 463, in myDomainEventCallback2
eventToString(event),
File "/usr/share/doc/libvirt-python-1.1.1/events-python/event-test.py", line 441, in eventToString
return eventStrings[event]
IndexError: tuple index out of range
myDomainEventCallback2 EVENT: Domain rhel7raw(-1) Stopped Crashed
<2> Can see the guest crashed status with the virsh domstate
# virsh domstate rhel7raw --reason
shut off (crashed)
Actual results:
it report error info while check the guest status with the libvirt-python script
when the guest os happens kernel panic
Expected results:
shouldn't report the error ,and should report the guest's status correctly
Comment 2Giuseppe Scrivano
2013-08-14 16:15:43 UTC
I am setting up the complete environment here to to test it since I am not able to trigger that notification with my current setup.
By looking at the code, it seems to be a missing value in the "eventStrings" enum for the event-test.py application.
So my bet is that the patch will not be anything more than this one-line:
diff --git a/examples/domain-events/events-python/event-test.py b/examples/domain-events/events-python/event-test.py
index b7c10d1..b916845 100644
--- a/examples/domain-events/events-python/event-test.py
+++ b/examples/domain-events/events-python/event-test.py
@@ -437,7 +437,8 @@ def eventToString(event):
"Resumed",
"Stopped",
"Shutdown",
- "PMSuspended" )
+ "PMSuspended",
+ "Crashed" )
return eventStrings[event]
Description of problem: it report error info while check the guest status with the libvirt-python script when the guest os happens kernel panic Version-Release number of selected component (if applicable): libvirt-1.1.1-2.el7.x86_64 kernel-3.10.0-4.el7.x86_64 qemu-kvm-1.5.2-2.el7.x86_64 How reproducible: 100% Steps 1.Prepare a guest with the following xml #virsh dumpxml rhel7 -- <on_crash>coredump-destroy</on_crash> -- 2.In terminal 1 running the following command #python /usr/share/doc/libvirt-python-1.1.1/events-python/event-test.py qemu:///system 3.Start the guest in terminal 2, then, login the guest and run the following command in the guest while the guest start completely #sync # printf '%b' '\x01' | dd of=/dev/port seek=$((16#505)) bs=1 count=1 4.Check the guest's relate info in host <1>In terminal 1 ,i didn't see the crashd event in the domain event handler,it just report the following error. # python /usr/share/doc/libvirt-python-1.1.1/events-python/event-test.py qemu:///system Using uri:qemu:///system Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3854, in _dispatchDomainEventLifecycleCallback cb(self, virDomain(self, _obj=dom), event, detail, opaque) File "/usr/share/doc/libvirt-python-1.1.1/events-python/event-test.py", line 463, in myDomainEventCallback2 eventToString(event), File "/usr/share/doc/libvirt-python-1.1.1/events-python/event-test.py", line 441, in eventToString return eventStrings[event] IndexError: tuple index out of range myDomainEventCallback2 EVENT: Domain rhel7raw(-1) Stopped Crashed <2> Can see the guest crashed status with the virsh domstate # virsh domstate rhel7raw --reason shut off (crashed) Actual results: it report error info while check the guest status with the libvirt-python script when the guest os happens kernel panic Expected results: shouldn't report the error ,and should report the guest's status correctly