Bug 1105530

Summary:	Blocking UI
Product:	Red Hat Enterprise Linux 6	Reporter:	Jiri Prajzner <dr3dwerkz>
Component:	virt-manager	Assignee:	Giuseppe Scrivano <gscrivan>
Status:	CLOSED WONTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.5	CC:	codong, dr3dwerkz, dyuan, gscrivan, juzhou, lkocman, mzhan, rbalakri, tzheng
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1138190 (view as bug list)		Environment:
Last Closed:	2014-12-15 14:15:32 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:
Bug Depends On:
Bug Blocks:	1138190

Description Jiri Prajzner 2014-06-06 10:48:18 UTC

Description of problem:
Upon losing a connection to VM(s), the virt. mgr. UI freezes and it's necessary to force quit the vrt. mgr. UI

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

How reproducible:
Every time

Steps to Reproduce:
1. Open virt. mgr. UI
2. Open a connection to VM(s)
3. Drop the connection on VM(s) side

Actual results:
The virt. mgr. UI freezes and the user has to force quit it

Expected results:
The virt. mgr. UI doesn't freeze and notifies about the dropped / lost connection and tries to reconnect (it probably tries to reconnect in the background, but this is not visible to the user)

Additional info:

Comment 1 Jiri Prajzner 2014-06-06 11:01:46 UTC

virt. mgr. version:
virt-manager-0.9.0-19.el6.x86_64

Comment 2 Giuseppe Scrivano 2014-06-30 14:06:41 UTC

the upstream version is affected by the same issue.  The solution seems to be in the usage of the virConnectSetKeepAlive API so the libvirt client (virt-manager in this case) keeps regularly pinging the server and be able to detect a dropped connection.

Comment 3 Giuseppe Scrivano 2014-07-02 13:30:43 UTC

fixed upstream with these patches:

commit 0c95a5e725256f552774db05cc2fa3bee3b1a25e
Author: Giuseppe Scrivano <gscrivan>
Date:   Tue Jul 1 15:01:58 2014 +0200

    console: prevent access to deleted objects
    
    last commits revealed that some objects can still be accessed by
    registered callbacks after the console is closed.  Unregister these
    callbacks.
    
    Signed-off-by: Giuseppe Scrivano <gscrivan>

commit dc1c22bd97aa9104a5299408934036530406f9ca
Author: Giuseppe Scrivano <gscrivan>
Date:   Tue Jul 1 13:06:05 2014 +0200

    virt-manager: check if still connected every 20 seconds
    
    Signed-off-by: Giuseppe Scrivano <gscrivan>

commit 8b94cfa073b517eb65ccf180004c76929c9ebf1a
Author: Giuseppe Scrivano <gscrivan>
Date:   Tue Jul 1 12:54:38 2014 +0200

    virtinst: add method to set connection keep-alive
    
    Signed-off-by: Giuseppe Scrivano <gscrivan>



This is going to be considered for 6.7, hopefully the change won't be too intrusive to be included.

Comment 4 tingting zheng 2014-07-28 09:34:46 UTC

Hi,Jiri Prajzner
   I am confused by the steps in description,what do you mean in step 3:Drop the connection on VM(s) side.
   I only can reproduce the bug by adding a remote connection,open a guest console,then destroy the network in remote host,then virt-manager freeze.

Comment 5 Jiri Prajzner 2014-09-04 08:03:54 UTC

(In reply to tingting zheng from comment #4)
> Hi,Jiri Prajzner
>    I am confused by the steps in description,what do you mean in step 3:Drop
> the connection on VM(s) side.
>    I only can reproduce the bug by adding a remote connection,open a guest
> console,then destroy the network in remote host,then virt-manager freeze.

hi,

the way you reprduced it is exactly what i meant.
apologies for vague description and late reply.

Comment 6 Giuseppe Scrivano 2014-12-15 14:15:32 UTC

I have evaluated the backport and unfortunately it doesn't apply cleanly in the virt-manager version we ship in RHEL-6.  I would prefer to not introduce new changes that are not already tested to address a non-serious issue like this one at a so late stage in the RHEL-6 development.  Please re-open if you disagree with this decision.