Bug 1030487
| Summary: | spice-server doesn't disconnect client tunnelled over ssh on VM shutdown | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | David Jaša <djasa> |
| Component: | virt-viewer | Assignee: | Marc-Andre Lureau <marcandre.lureau> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | cfergeau, codong, dblechte, djasa, fidencio, marcandre.lureau, mkrcmari, mzhan, rbalakri, tpelka, tzheng |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | virt-viewer-0.6.0-8.el7 | Doc Type: | Bug Fix |
| Doc Text: |
Cause: nc does not leave on server disconnect, and there doesn't seem to be any option to do that, leaving the client open, and a bunch of idle process
Consequence: client doesn't disconnect when tunneled over ssh on VM shutdown
Fix: Replace nc with socat, when socat is available
Result: Clients tunneled over ssh can disconnect on VM shutdown
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-05 13:38:31 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
David Jaša
2013-11-14 14:33:02 UTC
(In reply to David Jaša from comment #0) > Description of problem: > spice-server doesn't disconnect client tunnelled over ssh on VM shutdown > > Version-Release number of selected component (if applicable): > spice-server-0.12.4-3.el7.x86_64 > > How reproducible: > always > > Steps to Reproduce: > 1. fire up libvirt VM > 2. connect to the VM over ssh: virt-viewer -c qemu+ssh://root@host/system > vm_name > 3. shut the VM down How do you shut down exactly? What is the guest OS? Can you verify qemu state when shuting down? Can you get qemu/spice-server log? thanks > > Actual results: > client stays connected displaying last screen of the VM. A dozen of lines > like this are printed to the console: > (virt-viewer:32748): GSpice-CRITICAL **: spice_inputs_key_release: assertion > `SPICE_CHANNEL(channel)->priv->state != SPICE_CHANNEL_STATE_UNCONNECTED' > failed > > Expected results: > client disconnects > > Additional info: > I tested 6.5 and 7.0 clients and servers: > client \ host 6.5 7.0 > --------------------------------------------- > 6.5 disconnects stays connected > 7.0 disconnects stays connected > --> assigning to 7.0 spice-server This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. (In reply to Marc-Andre Lureau from comment #1) > ... > How do you shut down exactly? from within the guest. > What is the guest OS? RHEL6 but that shouldn't matter > Can you verify qemu state when shuting down? Can you get qemu/spice-server log? > qemu process exits. There is a bunch of sshd processes left server-side that exit on client exit. Curiously enough, netstat doesn't show any connections on either side after the domain shuts down while client is still running. Qemu log shows nothing interesting (just what it says on any VM shutdown), "virt-viewer --debug" says around actual VM shutdown this: (virt-viewer:22325): virt-viewer-DEBUG: Dispatch handler 12 2 0x23086b0 (virt-viewer:22325): virt-viewer-DEBUG: Dispatch handler 12 1 0x23086b0 (virt-viewer:22325): virt-viewer-DEBUG: Update timeout 0x20a1170 1 0 (virt-viewer:22325): virt-viewer-DEBUG: Dispatch timeout 0x20a1170 0x35898e5ce0 1 0x2306f50 (virt-viewer:22325): virt-viewer-DEBUG: Update timeout 0x20a1170 1 -1 (virt-viewer:22325): virt-viewer-DEBUG: Got domain event 6 0 (virt-viewer:22325): virt-viewer-DEBUG: Dispatch handler 12 1 0x23086b0 (virt-viewer:22325): virt-viewer-DEBUG: Update timeout 0x20a1170 1 0 (virt-viewer:22325): virt-viewer-DEBUG: Dispatch timeout 0x20a1170 0x35898e5ce0 1 0x2306f50 (virt-viewer:22325): virt-viewer-DEBUG: Update timeout 0x20a1170 1 -1 (virt-viewer:22325): virt-viewer-DEBUG: Got domain event 5 0 (virt-viewer:22325): virt-viewer-DEBUG: Dispatch handler 12 1 0x23086b0 Based on last comment, I understand the bug title is rather misleading. It looks like it should be moved to virt-viewer. Probably. What about the dangling sshd processes? (In reply to David Jaša from comment #5) > Probably. What about the dangling sshd processes? they are not started by spice server, but by virt-viewer. If qemu exited, this bug has probably very little to do with qemu/spice-server side. this has to do with nc not leaving on server disconnect. Sadly, I don't see any nc option that would change that behaviour. When using --recv-only, nc quits, but that's not what we want. Daniel, what do you think? *** Bug 1075959 has been marked as a duplicate of this bug. *** virt-viewer can ask libvirt to get a notification from libvirt when the guest state changes. It should then be possible to close the tunnel and clean things up when a "shutdown" event is detected. (In reply to Christophe Fergeau from comment #10) > virt-viewer can ask libvirt to get a notification from libvirt when the > guest state changes. It should then be possible to close the tunnel and > clean things up when a "shutdown" event is detected. Actually, if the reboot is done from within the guest, I'm not sure libvirt will be able to emit an event. I can reproduce with virt-viewer-0.6.0-7.el7.x86_64 VERIFY with virt-viewer-0.6.0-8.el7.x86_64 Steps: 1. Prepare spice guest on host A, install virt-viewer on host B 2. Install "socat" on two hosts 3. On B: # virt-viewer -c qemu+ssh://root.4.104/system $vm 4. on A: # virsh destroy $vm Retest the case, and shutdown the guest within it Result, virt-viewer connection on host B closes ASAP after the guest is power off. As the result, set VERIFIED. 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. https://rhn.redhat.com/errata/RHBA-2015-0295.html |