Bug 742055
| Summary: | virt-manager loses connection if it receives dominfo error while guest is shutting down | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Eric Blake <eblake> |
| Component: | virt-manager | Assignee: | Cole Robinson <crobinso> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | bderzhavets, jwu, laurent, linuxdev-ofuku, mzhan, rwu, zpeng |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Occasionally, if virt-manager tried to read a domain's information while that domain was shutting down, virt-manager would receive an error from libvirt, and incorrectly close the libvirt connection in the UI. virt-manager has been changed to expect errors in this case and not incorrectly close the libvirt connection.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 12:39:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 727267, 735357 | ||
In case it is relevant, I was also running: qemu-kvm-0.12.1.2-2.193.el6.x86_64 libvirt-0.9.4-13.el6.x86_64 Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. Is this 100% reproducible? Does it require the full screen setup you mention, or is it just specific to 2 running vms, or one fullscreen vm, etc? Deferring to 6.3 for now I haven't seen it in a few days, but I also haven't been running multiple VMs, so I'm not sure it is 100% reproducible. I'll post more the next time it happens to me; deferring to 6.3 seems okay. The issue doesn't seem to be related to fullscreen mode.
With Virt-manager, libvirt resets the connection when I shutdown a VM
if the VNC window is not open until the VM is completely shutdown. I can reproduce the issue when there is one or more running guests.
I get the following error message:
Error polling connection 'qemu:///system': Unable to read from monitor: Connection reset by peer
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 440, in _tick
conn.tick()
File "/usr/share/virt-manager/virtManager/connection.py", line 1507, in tick
vm.tick(now)
File "/usr/share/virt-manager/virtManager/domain.py", line 1526, in tick
info = self._backend.info()
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1411, in info
if ret is None: raise libvirtError ('virDomainGetInfo() failed', dom=self)
libvirtError: Unable to read from monitor: Connection reset by peer
I'm using Virt-manager 0.9.0 and libvirt 0.9.6.
I can reproduce the issue exactly like described in Comment #6 Environment :- Qemu-kvm 0.15.1, Libvirt 0.9.6 , Virt-manager 0.9.0 on top of Ubuntu Oneiric. Spice session initiated via Virt-Manager is connected via spicy. After domain shutdown :- Error polling connection 'qemu:///system': Unable to read from monitor: Connection reset by peer Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 440, in _tick conn.tick() File "/usr/share/virt-manager/virtManager/connection.py", line 1507, in tick vm.tick(now) File "/usr/share/virt-manager/virtManager/domain.py", line 1531, in tick info = self._backend.info() File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1411, in info if ret is None: raise libvirtError ('virDomainGetInfo() failed', dom=self) libvirtError: Unable to read from monitor: Connection reset by peer Just one guest. Restart of libvirtd daemon may allow 2-3 (max) successful shutdowns. Then :- Error polling connection 'qemu:///system': Unable to read from monitor: Connection reset by peer > I can reproduce the issue exactly like described in Comment #6
Disregard this sentence. Same issue , but another environment.
When spicy window showing shutdown messages gets closed, error window pops up.
There's another similar bug report (bug 757547), but not duping since this one has more info but the other one has partner info attached. *** Bug 757947 has been marked as a duplicate of this bug. *** Fixed upstream now; http://git.fedorahosted.org/git?p=virt-manager.git;a=commit;h=5bf341052d1f8c1ee5499b6a59c4b237b071523a Fixed in virt-manager-0.9.0-8.el6 This bug can be reproduced with: kernel-2.6.32-220.el6.x86_64 libvirt-0.9.4-14.el6.x86_64 virt-manager-0.9.0-6.el6.x86_6 python-virtinst-0.600.0-5.el6.noarch Verified with: kernel-2.6.32-220.el6.x86_64 libvirt-0.9.10-0rc2.el6.x86_64 python-virtinst-0.600.0-7.el6.noarch virt-manager-0.9.0-9.el6.x86_64 Steps: 1. Prepared two guests (rhel6.2 and win7) with VNC graphics device. 2. Running all the guests. 3. Login the guest rhel6.2 and shutdown it by guest's os function, not using the virt-manager tool button. 4. Check the status of guests and virt-manager. All of them work well without error message. 5. Changed the graphics device to Spice and do step2-step4. Guests and virt-manager work well without error message. Changed the status to VERIFIED.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Occasionally, if virt-manager tried to read a domain's information while that domain was shutting down, virt-manager would receive an error from libvirt, and incorrectly close the libvirt connection in the UI. virt-manager has been changed to expect errors in this case and not incorrectly close the libvirt connection.
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/RHBA-2012-0785.html |
Description of problem: I'm running virt-manager on a dual-screen setup, and had one of my two screens dedicated to one VM running in full-screen mode, while the other screen was running a second VM in windowed mode. I initiated a shutdown of the guest in the fullscreen window, and when it exited, I got a traceback message, and virt-manager closed the connection to libvirtd (in turn losing the windowed VM in the other monitor). Version-Release number of selected component (if applicable): virt-manager-0.9.0-6.el6.x86_64 How reproducible: Doesn't happen when the focus is not in the guest in full-screen mode, but appears to be pretty reliable if the focus is on the full-screen guest shutting down Steps to Reproduce: 1. shutdown a guest running in full-screen mode, and while that guest has focus 2. 3. Actual results: traceback popped up, and virt-manager lost the connection and all windows associated with the connection Error polling connection 'qemu:///system': Unable to read from monitor: Connection reset by peer Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 440, in _tick conn.tick() File "/usr/share/virt-manager/virtManager/connection.py", line 1507, in tick vm.tick(now) File "/usr/share/virt-manager/virtManager/domain.py", line 1531, in tick info = self._backend.info() File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1406, in info if ret is None: raise libvirtError ('virDomainGetInfo() failed', dom=self) libvirtError: Unable to read from monitor: Connection reset by peer Expected results: the guest that just shut down should pop out of fullscreen back into windowed mode with the typical "Guest not running" message, no other windows should be affected, and virt-manager should not lose the connection Additional info: