Bug 1698077

Summary: connecting to a hypervisor takes ages
Product: [Fedora] Fedora Reporter: Martin Kolman <mkolman>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 29CC: berrange, crobinso, mkolman
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-24 12:37:49 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
virt-manager --debug output from local hypervisor connect attemp
none
virt-manager --debug output from local hypervisor connect attemp + couple remote hypervisors none

Description Martin Kolman 2019-04-09 14:50:45 UTC 
Description of problem:
I'm running virt-manager 2.1.0 on Fedora 29 and any connection attempts to both local KVM hypervisors as well as remote libvirt instances (over SSH as root) in most cases take ages. What was an instantaneous operation before (~couple seconds) is not taking many minutes.

Version-Release number of selected component (if applicable):
2.1.0 @ Fedora 29

How reproducible:
Very often - sometimes a connection attempt succeeds rather quickly, but in most cases it's in "connecting..." for many minutes without any feedback.

Steps to Reproduce:
1. start virt-manager
2. connect to a local or remote hypervisor

Actual results:
The connection attempt takes many minutes.

Expected results:
The connection attempt takes a couple seconds, as before.

Additional info:
Please let me know if you need any debugging information & how to obtain it.
Comment 1 Cole Robinson 2019-04-09 15:47:42 UTC 
Thanks for the report. I haven't heard of an issue like that before.

First thing will be to see if you can produce from the command line with 'virsh --connect $URI'. 'Connection Details' panel in virt-manager will tell you the URI for any affected connections.

If it's only virt-manager, please provide virt-manager --debug when reproducing. If virsh is failing too, try doing 'sudo journalctl --follow' while reproducing and see if anything interesting pops up
Comment 2 Martin Kolman 2019-04-10 13:36:02 UTC 
Created attachment 1554235 [details]
virt-manager --debug output from local hypervisor connect attemp

I've tun virt-manager --debug, then connected to the local hypervisor. It took quite a while but seemingly was a bit faster than yesterday. Still, woulkd expect this to be basically instant for the local hypervisor.

Once virt-manager finally connected I've quite it and saved the log.
Comment 3 Martin Kolman 2019-04-10 13:40:05 UTC 
Created attachment 1554238 [details]
virt-manager --debug output from local hypervisor connect attemp + couple remote hypervisors

I've started virt-manager --debug, then connected to the local hypervisor and a couple remote hypervisors (all Fedora based, some on machines on local network, some on VMs in an OpenStack instance). When virt-manager finally connected to all the hypervisors I've quite it and saved the log.

From a cursory look at the log, I see quite some lines that look like some leftoverers from previous VM runs (out single use VMs we use for running of Anaconda integration tests are generally called kstest*). I could imagine if for every run some data item was saved it could make things grind to a halt over time.

On the other hand there was no such delay with older virt-manager versions and there have not been that many more runs on the hypervisors since then.
Comment 4 Cole Robinson 2019-04-24 12:37:49 UTC 
We determined this is all tied in with bug 1698088, so duping to that one

*** This bug has been marked as a duplicate of bug 1698088 ***