Bug 810576

Summary: virt-manager doesn't survive transient libvirt outages
Product: Red Hat Enterprise Linux 6 Reporter: Michael Hines <mrhines>
Component: virt-managerAssignee: virt-mgr-maint
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.2CC: acathrow, cwei, dallan, djasa, gscrivan, jwu, lcui, mjenner, mkletzan, mzhan, tzheng, zpeng
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-10 08:16:58 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:
Attachments:
Description Flags
example reconnect patch to /usr/share/virt-manager/virtManager/connection.py none

Description Michael Hines 2012-04-06 20:14:25 UTC
Created attachment 575819 [details]
example reconnect patch to /usr/share/virt-manager/virtManager/connection.py

Description of problem:
We had a group of machines with faulty hardware (of various kinds) which would cause the hypervisors to become unavailable for periods of seconds. (Very infrequent).

However, virt-manager would throw away all the libvirt connections and show "disconnected" even though the machines would come back to life a few seconds or minutes later....

A simple patch to /usr/share/virt-manager/virtManager.py solved the problem for us, but it would be nice to have this fixed in the future.

As it stands, when virt-manager detects a connection error, it just gives up until the user re-clicks the connection and instructs virt manager to attempt to reconnect again.

Shouldn't virt-manager auto-reconnect or at least *try* to auto-reconnect and then give up later?

I've attached a (crude) patch that fixed the problem for us, but such functionality could be generalized to any kind of transient problem in which the libvirt daemon became unavailable but was not permanently dead.

Version-Release number of selected component (if applicable):

Any version.

How reproducible:
100% reproducible.

Steps to Reproduce:
1. start virt manager
2. login to hypervisor and 'service libvirtd restart'
  
Actual results:
Virt-manager reports disconnected.


Expected results:
Virt-manager would attempt to reconnect a few times and give up later.


Additional info:

Comment 2 Cole Robinson 2012-04-16 14:32:07 UTC
Not a bad idea in principle. Not that virt-manager should be patched to support crappy hardware, but I think the common case here is when libvirtd is restarted.

That patch isn't exhaustive enough though, and I'm hesitant to introduce a change like this at this point in the 6.3 cycle. Deferring to 6.4

Comment 3 Michael Hines 2012-04-16 14:37:55 UTC
Thanks.

Yeah, there's no hurry. I fully expected the example patch to be completely replaced by somebody else. The quick patch I wrote just solved my immediate needs.

Comment 5 RHEL Program Management 2012-07-10 08:44:01 UTC
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.

Comment 6 RHEL Program Management 2012-07-11 01:56:41 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 8 Dave Allan 2013-04-09 02:22:35 UTC
*** Bug 884739 has been marked as a duplicate of this bug. ***

Comment 9 Martin Kletzander 2013-04-23 10:12:05 UTC
The patch should definitely be more accurate, but as you said, this is really wanted feature and I think it would be very nice to have.  But since this isn't as big deal as various bug, we cannot give it full priority.  I'll have a look at it in the future.

Comment 10 RHEL Program Management 2014-04-10 08:16:58 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.