Bug 1698077 - connecting to a hypervisor takes ages
Summary: connecting to a hypervisor takes ages
Keywords:
Status: CLOSED DUPLICATE of bug 1698088
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 29
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-09 14:50 UTC by Martin Kolman
Modified: 2019-04-24 12:37 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-04-24 12:37:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
virt-manager --debug output from local hypervisor connect attemp (64.33 KB, text/plain)
2019-04-10 13:36 UTC, Martin Kolman
no flags Details
virt-manager --debug output from local hypervisor connect attemp + couple remote hypervisors (205.20 KB, text/plain)
2019-04-10 13:40 UTC, Martin Kolman
no flags Details

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 ***


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