This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 489250 - virsh migrate is not allowing for authentication credentials when connecting to the destination
virsh migrate is not allowing for authentication credentials when connecting ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
5.4
All Linux
low Severity medium
: rc
: ---
Assigned To: Daniel Veillard
Virtualization Bugs
:
: 490255 (view as bug list)
Depends On: 490255
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-09 01:34 EDT by Vivian Bian
Modified: 2016-04-26 10:04 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:23:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the xml file to create the guest. (1.03 KB, text/xml)
2009-03-09 01:34 EDT, Vivian Bian
no flags Details
migration with SASL debug info (10.64 KB, text/plain)
2009-06-16 23:50 EDT, Nan Zhang
no flags Details

  None (edit)
Description Vivian Bian 2009-03-09 01:34:06 EDT
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.
Comment 1 Daniel Berrange 2009-03-09 07:05:15 EDT
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.
Comment 2 Alan Pevec 2009-03-09 07:25:21 EDT
(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?
Comment 3 Perry Myers 2009-03-09 13:30:21 EDT
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.
Comment 4 Alan Pevec 2009-03-16 05:56:01 EDT
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.
Comment 5 Vivian Bian 2009-03-20 04:53:44 EDT
this bug still exists in snap5.2
Comment 6 Vivian Bian 2009-03-20 05:28:38 EDT
this bug still exists in snap5.2
Comment 7 Alan Pevec 2009-03-20 10:58:22 EDT
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.
Comment 8 Perry Myers 2009-03-30 23:18:04 EDT
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
Comment 9 Daniel Berrange 2009-03-31 06:16:12 EDT
The fix for this was merged in upstream CVS

http://www.redhat.com/archives/libvir-list/2009-March/msg00358.html
Comment 10 Daniel Berrange 2009-03-31 11:21:37 EDT
*** Bug 490255 has been marked as a duplicate of this bug. ***
Comment 11 Gerrit Slomma 2009-04-01 17:45:34 EDT
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?
Comment 12 Gerrit Slomma 2009-04-01 17:57:56 EDT
And uri shouldn't be null i suppose?
Comment 13 Daniel Berrange 2009-06-12 07:11:04 EDT
The fix for virsh to use virConnectOpenAuth everywhere is included in the 0.6.3 build of libvirt, so switching to MODIFIED.
Comment 16 Nan Zhang 2009-06-16 23:50:04 EDT
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@dhcp-66-70-85.nay.redhat.com: userPassword
root@dhcp-66-70-85.nay.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:
Comment 17 Daniel Berrange 2009-06-17 17:37:59 EDT
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.
Comment 18 Nan Zhang 2009-06-17 23:44:19 EDT
This bug is already fixed with 0.6.3-10.el5 on rhel-5.4, file a new bug 506641 for comment #16.
Comment 20 errata-xmlrpc 2009-09-02 05:23:26 EDT
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

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