Bug 854135
Summary: | The libvirt domain event handler can't catch the disconnecting information when disconnected the guest | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | zhenfeng wang <zhwang> |
Component: | libvirt | Assignee: | Jiri Denemark <jdenemar> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.4 | CC: | acathrow, dyasny, dyuan, gsun, mzhan, rwu |
Target Milestone: | rc | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-0.10.2-0rc1.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-02-21 07:23:09 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
zhenfeng wang
2012-09-04 07:14:00 UTC
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> 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> 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 |