Red Hat Bugzilla – Bug 854135
The libvirt domain event handler can't catch the disconnecting information when disconnected the guest
Last modified: 2013-02-21 02:23:09 EST
Description of problem: The libvirt domain event handler can't catch the disconnecting information when disconnected the guest Version-Release number of selected component (if applicable): libvirt-0.10.1-1.el6.x86_64 qemu-kvm-0.12.1.2-2.305.el6.x86_64 kernel-2.6.32-298.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. # virsh edit testhd1 <graphics type='spice' port='5900' autoport='no' keymap='en-us'/> 2. In the first terminal run: # python /usr/share/doc/libvirt-python-x.x.x/events-python/event-test.py qemu:///system 3.run the guest in another terminal, connected the guest with spicec,then disconnected it # virsh start testtwon # /usr/libexec/spicec -h 127.0.0.1 -p 5900 # /usr/libexec/spicec -h 127.0.0.1 -p 5900 ^CWarning: abort 4.event-test.py will only get 7 connectting information,but no disconnecting information myDomainEventGraphicsCallback: Domain testhd1(49) 1 none myDomainEventGraphicsCallback: Domain testhd1(49) 1 none myDomainEventGraphicsCallback: Domain testhd1(49) 1 none myDomainEventGraphicsCallback: Domain testhd1(49) 1 none myDomainEventGraphicsCallback: Domain testhd1(49) 1 none myDomainEventGraphicsCallback: Domain testhd1(49) 1 none myDomainEventGraphicsCallback: Domain testhd1(49) 1 none Actual results: event-test.py will only get 7 connectting information,but no disconnecting information Expected results: Both connecting and disconnecting information will get by the event-test.py Additional info
You claim this is a regression, in what previous version of libvirt was this working?
I can reproduce this bug with libvirt-0.10.1-1.el6.x86_64 , but can not reproduce with libvirt-0.9.10-21.el6_3.4.x86_64
Oops, this is because some RHEL-only changes were not applied after libvirt was rebased to the newest upstream. The following commit from RHEL 6.3 commit 18c5f2a4c8429ca1c8e012478028176f177b7ceb Author: Daniel P. Berrange <berrange@redhat.com> Date: Fri Dec 17 14:55:29 2010 +0100 Emit graphics events when a SPICE client connects/disconnects RHEL-6 only, no upstream Wire up the domain graphics event notifications for SPICE. This uses the custom __com.redhat_SPICE_INITIALIZED and __com.redhat_SPICE_DISCONNECTED events. Since there is no explicit CONNECTED event available, we fake one when getting the INITIALIZED event * src/qemu/qemu_monitor_json.c: Wire up SPICE graphics events was incorporated upstream but without the mapping to custom events. When libvirt was rebased, the mapping was not reapplied. Anyway, our code requires data/server/auth to be always present while qemu mentions it is optional for SPICE_INITIALIZED and does not mention it at all for SPICE_{DIS,}CONNECTED.
The following is the reason why libvirtd ignores the DISCONNECTED event: 2012-09-04 13:45:58.755+0000: 29907: debug : qemuMonitorJSONIOProcessEvent:121 : handle SPICE_DISCONNECTED handler=0x4ab9e0 data=0x886370 2012-09-04 13:45:58.755+0000: 29907: warning : qemuMonitorJSONHandleGraphics:675 : missing auth scheme in graphics event
For upstream and recent RHEL versions of qemu-kvm this issue is fixed by v0.10.1-22-g965ccdd: commit 965ccdd1bddd20abb14446257be39f2392cd50f7 Author: Jiri Denemark <jdenemar@redhat.com> Date: Tue Sep 4 16:52:47 2012 +0200 qemu: Do not require auth scheme in graphics events Only VNC_{{DIS,}CONNECTED,INITIALIZED} and SPICE_INITIALIZED events are documented to support server/auth field and even there it is marked as optional. Emit "" auth scheme in case QEMU didn't send it.
Eh, I wonder what code I was looking at before but the non-upstream part of commit 18c5f2a4c8429ca1c8e012478028176f177b7ceb I mentioned in comment 5 *is* included in current libvirt-0.10.1-1.el6 as a RHEL-only patch. Thus we are done and we don't need to do anything beyond the fix from comment 7.
pkgs # rpm -qa|grep libvirt libvirt-0.10.2-0rc1.el6.x86_64 qemu-img-rhev-0.12.1.2-2.312.el6.x86_64 kernel-2.6.32-308.el6.x86_64 steps 1. # virsh edit testks <graphics type='spice' port='5900' autoport='no' keymap='en-us'/> 2. In the first terminal run: # python /usr/share/doc/libvirt-python-x.x.x/events-python/event-test.py qemu:///system 3.run the guest in another terminal, connected the guest with spicec,then disconnected it # virsh start testks # /usr/libexec/spicec -h 127.0.0.1 -p 5900 # /usr/libexec/spicec -h 127.0.0.1 -p 5900 ^CWarning: abort 4.event-test.py record both the connectting information and the disconnecting information myDomainEventGraphicsCallback: Domain testks(12) 0 myDomainEventGraphicsCallback: Domain testks(12) 1 none myDomainEventGraphicsCallback: Domain testks(12) 1 none myDomainEventGraphicsCallback: Domain testks(12) 0 myDomainEventGraphicsCallback: Domain testks(12) 0 myDomainEventGraphicsCallback: Domain testks(12) 0 myDomainEventGraphicsCallback: Domain testks(12) 1 none myDomainEventGraphicsCallback: Domain testks(12) 1 none myDomainEventGraphicsCallback: Domain testks(12) 0 myDomainEventGraphicsCallback: Domain testks(12) 1 none myDomainEventGraphicsCallback: Domain testks(12) 1 none myDomainEventGraphicsCallback: Domain testks(12) 0 myDomainEventGraphicsCallback: Domain testks(12) 1 none myDomainEventGraphicsCallback: Domain testks(12) 2 myDomainEventGraphicsCallback: Domain testks(12) 2 myDomainEventGraphicsCallback: Domain testks(12) 2 myDomainEventGraphicsCallback: Domain testks(12) 2 myDomainEventGraphicsCallback: Domain testks(12) 2 myDomainEventGraphicsCallback: Domain testks(12) 2 IN the vnc senarios myDomainEventGraphicsCallback: Domain testks(11) 0 none myDomainEventGraphicsCallback: Domain testks(11) 1 none myDomainEventGraphicsCallback: Domain testks(11) 2 none Now I have a wonder that why it only report 3 events in vnc senarios,however it reported 6 events in the spice senarios ,is this normal? From the patch I knew that 0 means connet ;1 means initiallize; 2 means disconnect ,why the initiallize number (7)is more than connect (6)and initiallize (6)? thanks
AFAIK it's normal. I'm not sure why it is but qemu just sends a lot of events when a spice client connects and disconnects. I'm not sure what is the reason for that.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0276.html