Created attachment 334466 [details] the xml file to create the guest. Description of problem: tried to migrate living guest to other host,but got the error like this: libvir:Remote error : Failed to start SASL negotiation: -4 (SASL (-4) : no mechanism available: No worhy mechs found) Version-Release number of selected component (if applicable): ovirt-node-image-1.0-1.snap3.el5ovirt libvirt-0.5.1-3.el5ovirt two boxes with Intel-VT boxes How reproducible: Always Steps to Reproduce: [in the destination host] 1.#qemu-img create xxx.img XG (the image name and size are the same with the ones in source box) 2.service libvirtd restart [in the source box] 3.# virsh migrate --live single qemu+tcp://10.66.70.10/system Actual results: libvir:Remote error : Failed to start SASL negotiation: -4 (SASL (-4) : no mechanism available: No worhy mechs found) Expected results: the guest could be migrated successfully Additional info: if there are two different company boxes (Intel and AMD) the migration won't succeed ,but will succeed in the same company boxes after shutoff the sasl authentication.
What SASL mechanism have you got enabled on the destination ? I think the most likely cause of the problem is that virsh is not allowing for authentication credentials when connecting to the destination. /* Temporarily connect to the destination host. */ dconn = virConnectOpen (desturi); if (!dconn) goto done; When it should be using ctl->conn = virConnectOpenAuth(ctl->name, virConnectAuthPtrDefault, ctl->readonly ? VIR_CONNECT_RO : 0); to allow prompting of username + password for auth mechanisms which need it. As it currently stands, only GSSAPI would work.
(In reply to comment #1) > What SASL mechanism have you got enabled on the destination ? Yeah, it's digest-md5 as configured in ovirt Node stand-alone mode. > I think the most likely cause of the problem is that virsh is not allowing for > authentication credentials when connecting to the destination. yes, that was my conclusion after reading the source as well. Changing to libvirt, do we also need to clone to Virt.Tools/libvirt or just change the Product to Virt.Tools?
We shouldn't just change the product to Virt.Tools since we do need to track this for the RHEVH product. But you can certainly clone this for Virt.Tools so that it can be tracked upstream.
I guess upstream BZ should be first, which is then cloned for RHEVH product. If I clone this BZ, upstream public BZ will depend on this product private BZ.
this bug still exists in snap5.2
This needs to be fixed by the upstream and then again there are no plans to update libvirt in RHEV-H 1.0, since only supported virt management will be VDSM. Libvirt is left in 1.0 image only to help testing efforts. Chris, please clear rhevh-1.0 flag.
Moving to RHEL since libvirt is not supported in RHEV1.0 production builds and this problem will need to be addressed in RHEL5.4 release
The fix for this was merged in upstream CVS http://www.redhat.com/archives/libvir-list/2009-March/msg00358.html
*** Bug 490255 has been marked as a duplicate of this bug. ***
Works so far as the dreaded SASL negotiation-error is gone. But migration still doesn't work. After the prompt for the password the prompt of virsh does not come back. At the destination host nothing arrives and the virsh gets stuck and must get restarted via init-script. Setup: kvm-84 built from sourceforge sources qemu-0.9.1-11.el5 & qemu-img-0.9.1-11.el5 from EPEL libvirt-0.6.1 & libvirt-python-0.6.1 built from http://libvirt.org/sources sources + applied patch from http://www.redhat.com/archives/libvir-list/2009-March/msg00358.html + applied patch from https://www.redhat.com/archives/libvir-list/2009-March/msg00503.html when started virsh with LIBVIRT_DEBUG=1 this happens after the SASL-authentication (...) 23:34:52.474: debug : doRemoteOpen:822 : Adding Handler for remote events 23:34:52.474: debug : doRemoteOpen:829 : virEventAddHandle failed: No addHandleImpl defined. continuing without events. 23:34:52.474: debug : do_open:925 : driver 3 remote returned SUCCESS 23:34:52.474: debug : do_open:945 : network driver 0 Test returned DECLINED 23:34:52.474: debug : do_open:945 : network driver 1 remote returned SUCCESS 23:34:52.474: debug : do_open:967 : storage driver 0 Test returned DECLINED 23:34:52.474: debug : do_open:967 : storage driver 1 remote returned SUCCESS 23:34:52.474: debug : do_open:988 : node driver 0 Test returned DECLINED 23:34:52.474: debug : do_open:988 : node driver 1 remote returned SUCCESS 23:34:52.474: debug : virDomainMigrate:2701 : domain=0x1fd5ab30, dconn=0x1fd5ab90, flags=0, dname=(null), uri=(null), bandwidth=0 23:34:52.474: debug : call:6462 : Doing call 60 (nil) 23:34:52.474: debug : call:6532 : We have the buck 60 0x1fda6cd0 0x1fda6cd0 (...) In virt-manager 0.7.0 built from source of virt-manager.et.redhat.com i get this message: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 556, in migrate_domain vm.migrate(destconn) File "/usr/share/virt-manager/virtManager/domain.py", line 1342, in migrate self.vm.migrate(self.connection.vmm, flags, None, dictcon.get_short_hostname(), 0) File "/usr/lib64/python2.4/site-packages/libvirt.py", line 378, in migrate if ret is None:raise libvirtError('virDomainMigrate() failed', dom=self) libvirtError: invalid argument in only tcp URIs are supported for KVM migrations Where comes the last message from? Only occurrence known to me is in qemu_driver.c, but there i changed this string to "Migration called but only tcp URIs are supporte for KVM migrations" Anything missed by me?
And uri shouldn't be null i suppose?
The fix for virsh to use virConnectOpenAuth everywhere is included in the 0.6.3 build of libvirt, so switching to MODIFIED.
Created attachment 348205 [details] migration with SASL debug info Configure libvirtd with SASL, but will hang during migration. See attached detailed debug info. [root@dhcp-66-70-85 ~]# sasldblistusers2 -f /etc/libvirt/passwd.db fred.redhat.com: userPassword root.redhat.com: userPassword [root@dhcp-66-70-66 ~]# virsh migrate --live kvmtest qemu+tcp://10.66.70.85/system Please enter your authentication name:root Please enter your password:
The debug data from the log in comment #16 indicates that it successfull completed authentication. Ergo this bug should be marked VERIFIED. Please file a new bug for problems with migration hanging, since that's not related to this bug report.
This bug is already fixed with 0.6.3-10.el5 on rhel-5.4, file a new bug 506641 for comment #16.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1269.html