Bug 810576 - virt-manager doesn't survive transient libvirt outages
virt-manager doesn't survive transient libvirt outages
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager (Show other bugs)
6.2
x86_64 Linux
unspecified Severity low
: rc
: ---
Assigned To: virt-mgr-maint
Virtualization Bugs
:
: 884739 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-06 16:14 EDT by Michael Hines
Modified: 2014-04-10 04:16 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-10 04:16:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
example reconnect patch to /usr/share/virt-manager/virtManager/connection.py (1.53 KB, application/octet-stream)
2012-04-06 16:14 EDT, Michael Hines
no flags Details

  None (edit)
Description Michael Hines 2012-04-06 16:14:25 EDT
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 10:32:07 EDT
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 10:37:55 EDT
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 Product and Program Management 2012-07-10 04:44:01 EDT
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 Product and Program Management 2012-07-10 21:56:41 EDT
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-08 22:22:35 EDT
*** Bug 884739 has been marked as a duplicate of this bug. ***
Comment 9 Martin Kletzander 2013-04-23 06:12:05 EDT
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 Product and Program Management 2014-04-10 04:16:58 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.