Bug 490419 - virsh is not allowing for authentication credentials when connecting to the destination
virsh is not allowing for authentication credentials when connecting to the d...
Status: CLOSED DUPLICATE of bug 490255
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-16 06:00 EDT by Alan Pevec
Modified: 2016-04-26 15:11 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-16 06:53:28 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)

  None (edit)
Description Alan Pevec 2009-03-16 06:00:10 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 worthy mechs found) 

Version-Release number of selected component (if applicable):
libvirt-0.5.1

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 worthy 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.

--- Additional comment from berrange@redhat.com on 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.

--- Additional comment from apevec@redhat.com on 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 1 Alan Pevec 2009-03-16 06:53:28 EDT

*** This bug has been marked as a duplicate of bug 490255 ***

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