Created attachment 577744 [details] virt-manager debug output Description of problem: virt-manager drops the connection to a libvirtd when using qemu+tcp. virsh console connects fine. Version-Release number of selected component (if applicable): Clients: virt-manager-0.9.1-2.fc17.noarch libvirt-client-0.9.11-1.fc17.x86_64 Server (Debian squeeze-backports): libvirt-bin 0.9.8-2~bpo60+2 How reproducible: all the time Steps to Reproduce: 1. Configure a new connection in virt-manager using qemu+tcp as a protocol. 2. Connect and authenticate Actual results: The server connection stalls with the "Connecting" status - virt-manager switches the connection back to "disconnected" in the UI without having connected to the libvirtd after two minutes Expected results: See the running VMs on the libvirtd server Additional info: Starting virt-manager with the --debug option one can see that vm connects correctly but the fails after trying to get the details about the storage pools (see attachment for log) virsh itself connects fine and can list the storage pools without problems: [rsacha@novalima ~]$ virsh -c qemu+tcp://10.247.13.1:16509/system Please enter your authentication name: rsacha Please enter your password: Willkommen bei virsh, dem interaktiven Virtualisierungsterminal. Tippen Sie: 'help' für eine Hilfe zu den Befehlen 'quit' zum Beenden virsh # pool-info vg1 Name: vg1 UUID: 33703cf0-635f-6206-0a67-7cfb5c6c865b Status: laufend Persistent: yes Automatischer Start: yes Kapazität: 820,20 GB Zuordnung: 219,52 GB Verfügbar: 600,69 GB virsh # pool-info vg2 Name: vg2 UUID: 25fdd5e3-3a85-5183-a42f-62e5c2ce825b Status: laufend Persistent: yes Automatischer Start: yes Kapazität: 2,27 TB Zuordnung: 1,71 TB Verfügbar: 576,66 GB virsh # pool-info default Name: default UUID: 40785e08-681e-14e2-3ab6-deadec446830 Status: laufend Persistent: yes Automatischer Start: yes Kapazität: 984,31 GB Zuordnung: 618,23 GB Verfügbar: 366,08 GB virsh # pool-list Name Status Automatischer Start ----------------------------------------- default Aktiv yes vg1 Aktiv yes vg2 Aktiv yes
virt-manager URI is qemu+tcp://10.247.13.1/system. Does adding the port there make any difference? Try virt-manager --debug --connect qemu+tcp://10.247.13.1:16509/system And once connected with virsh, try a pool-refresh vg1, since that is the first call failing with virt-manager Beginning of the output failures 2012-04-16 16:45:06,367 (connection:1315): Couldn't fetch active pool 'vg1' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 1312, in _poll_helper check_obj(name, True) File "/usr/share/virt-manager/virtManager/connection.py", line 1291, in check_obj current[key] = build_class(self, obj, key, is_active) File "/usr/share/virt-manager/virtManager/storagepool.py", line 38, in __init__ self.refresh() File "/usr/share/virt-manager/virtManager/storagepool.py", line 115, in refresh self.pool.refresh(0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2116, in refresh if ret == -1: raise libvirtError ('virStoragePoolRefresh() failed', pool=self) libvirtError: End of file while reading data: Eingabe-/Ausgabefehler 2012-04-16 16:45:06,375 (connection:1287): Could not fetch pool 'vg2': End of file while reading data: Eingabe-/Ausgabefehler 2012-04-16 16:45:06,377 (connection:1287): Could not fetch pool 'default': End of file while reading data: Eingabe-/Ausgabefehler 2012-04-16 16:45:06,380 (cli:83): Uncaught exception: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/baseclass.py", line 33, in _safe_wrapper return func(*args) File "/usr/share/virt-manager/virtManager/connection.py", line 1241, in _open_notify self.tick() File "/usr/share/virt-manager/virtManager/connection.py", line 1468, in tick self._tick(noStatsUpdate) File "/usr/share/virt-manager/virtManager/connection.py", line 1489, in _tick newInterfaces, self.interfaces) = self._update_interfaces() File "/usr/share/virt-manager/virtManager/connection.py", line 1363, in _update_interfaces lookup_func, build_class) File "/usr/share/virt-manager/virtManager/connection.py", line 1269, in _poll_helper if not check_support(): File "/usr/share/virt-manager/virtManager/connection.py", line 549, in is_interface_capable virtinst.support.SUPPORT_CONN_INTERFACE) File "/usr/lib/python2.7/site-packages/virtinst/support.py", line 577, in check_conn_support return _check_support(conn, feature, conn) File "/usr/lib/python2.7/site-packages/virtinst/support.py", line 445, in _check_support minimum_libvirt_version) File "/usr/lib/python2.7/site-packages/virtinst/support.py", line 358, in _daemon_lib_ver return conn.getLibVersion() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3106, in getLibVersion if ret == -1: raise libvirtError ('virConnectGetLibVersion() failed', conn=self) libvirtError: End of file while reading data: Eingabe-/Ausgabefehler
Hi, you're right. If i do a a "virsh# pool-refresh vg1" the virsh console just hangs for like three minutes and then prints: virsh # pool-refresh vg1 Pool vg1 aktualisiert virsh # If I issue that command a second time it takes the same amount of time. Adding the port with virt-manager doesn't help. It disconnects after ~1 minute spewing the same errors on the console. HTH, Rouven
What distro and kernel are you on? Someone reported a similar issue with alt linux 3.3 kernel and lvm pools. https://bugzilla.redhat.com/show_bug.cgi?id=812654 Doing 'sudo LIBVIRT_DEBUG=1 libvirtd' and reproducing the virsh hang in another terminal will show lot's of output that might pinpoint the issue.
Hi - you're right again and I apologize: I have the same issue when i execute virsh pool-refresh vg1 on the libvirtd host itself - so virsh on fedora17 is not to blame ... The system is a Debian squeeze box with kernel, kvm-qemu and libvirt from squeeze-backports: linux-image: 3.2.0-0.bpo.1 qemu-kvm: 1.0+dfsg-8~bpo60+1 libvirt-bin: 0.9.8-2~bpo60+2 if i find the time i am going to post some debug results here. Thanks for helping out! Rouven
Okay, closing this bug. Please follow up with debian.