[virt-tools-list] virt-manager/libvirt backwards compatibility problem?
Whit Blauvelt
whit.virt at transpect.com
Thu Jul 14 14:41:43 UTC 2011
Hi,
Apologies to those who may receive this twice. I posted this and a couple of
followups to libvirt-users last Monday with no response. Since it's a
question that straddles the interests of the two lists, I'm hoping I can do
better here. The basic question:
- It appears that virt-manager and virsh, if run on a system with libvirt
0.9.x on it, cannot connect to systems whose libvirt is 0.8.x
- Is this generally the case, or just something needing additional
configuration on the several systems I've tested this on (with several
members of both the 0.9.x and 0.8.x series now)?
- If it is the general case, has this been documented? (Haven't found that,
but the documentation of this stuff is so sparse and scattered perhaps
I've missed it.)
- Is it a feature (that is, intentional) or a bug (which should/might be
fixed)?
Original post:
Wanting to test some recent features of libvirt, I installed 0.9.3 on a
couple of systems. It works fine on those, but since upgrading neither of
them can successfully connect with virt-manager or virsh to a couple of
other systems running libvirt 0.8.3. Even after upgrading virt-manager and
virtinst to the latest versions on the 0.9.3 systems, they fail like this
in virt-manager:
Unable to open a connection to the libvirt management daemon.
Libvirt URI is: qemu+ssh://root@192.168.1.67/system
Verify that:
- The 'libvirtd' daemon has been started
Cannot recv data: : Connection reset by peer
Traceback (most recent call last):
File "/usr/src/virt-manager-0.8.7/src/virtManager/connection.py", line
1055, in _try_open
None], flags)
File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 102, in
openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Cannot recv data: : Connection reset by peer
Virsh simple fails with:
error: Cannot recv data: : Connection reset by peer
error: failed to connect to the hypervisor
Since it's certain that the libvirtd daemon has been started on the other
systems (they have production VMs that are running), this leaves me puzzled.
This connection for virt-manager worked flawlessly for months when all the
systems had libvirt 0.8.3.
Is this a known incompatibility? Something I have to tweak somewhere?
Thanks,
Whit
More information about the virt-tools-list
mailing list