Bug 1167354
| Summary: | virt-viewer can not connect to spice VM when libvirt uses tcp port with sasl encryption | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | David Jaša <djasa> |
| Component: | virt-viewer | Assignee: | Virt Viewer Maint <virt-viewer-maint> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | cfergeau, dblechte, djasa, dyuan, fidencio, juzhou, mzhan, rbalakri, tzheng |
| Target Milestone: | rc | ||
| Target Release: | 7.2 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | virt-viewer-2.0-1.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-12 08:48:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1181288 | ||
| Bug Blocks: | |||
|
Description
David Jaša
2014-11-24 14:14:23 UTC
I suppose you are talking about RFE add user to SASL auth, which is in upstream now:
commit fce9201f2f27d90b0224f3dd5845a74e526b5480
Author: Fabiano Fidêncio <fidencio>
Date: Wed Oct 8 14:15:28 2014 +0200
Add support to handle username when connecting with SASL
Based on a patch from Dietmar Maurer <dietmar>
http://lists.freedesktop.org/archives/spice-devel/2013-October/015138.html
and related virt-viewer patch.
Could you try with upstream spice-gtk & virt-viewer? thanks
(In reply to Marc-Andre Lureau from comment #1) > I suppose you are talking about RFE add user to SASL auth, which is in > upstream now: No, I'm talking about libvirtd sasl. Spice auth/encryption is not affected at all, i.e. my VMs run by that libvirt use plain tcp without any authentication. That BTW means that we can have a corner case of libvirt needing credentials and then spice-server needing credentials - which might or might not be the same, depending on sasl configuration of both. (In reply to David Jaša from comment #2) > (In reply to Marc-Andre Lureau from comment #1) > > I suppose you are talking about RFE add user to SASL auth, which is in > > upstream now: > > No, I'm talking about libvirtd sasl. Spice auth/encryption is not affected > at all, i.e. my VMs run by that libvirt use plain tcp without any > authentication. > > That BTW means that we can have a corner case of libvirt needing credentials > and then spice-server needing credentials - which might or might not be the > same, depending on sasl configuration of both. Hmm. I was not able to setup my local machine to test it. However, I've tested against Christophe's machine and didn't have any problem. Can you test with upstream spice-gtk[0]/virt-viewer[1]? If it's not handy for you, please, give me access to your test machine and I'll try it. [0]: Necessary patches from spice-gtk: 04e2741c687ec9f73f07429202e0d7da9c90cfcf af3ee8043e2e04a81858e4d4f10df4c26ada9d51 0fe5be04ef762a8ae4057f45e64cfdf6ba426102 fce9201f2f27d90b0224f3dd5845a74e526b5480 [1]: Necessary patches from virt-viewer: 04e02148b29226daca6f9ad96ee4986b7ea3d600 69b3096f51bf2b6e9d1606b9fd49499899886ac7 Hey David, Have you been able to test with upstream spice-gtk/virt-viewer? Let me know if you still face the problem or if I can close this. (In reply to Fabiano Fidêncio from comment #4) > Hey David, > > Have you been able to test with upstream spice-gtk/virt-viewer? > Let me know if you still face the problem or if I can close this. The issue is gone in Fedora 21 virt-viewer. (In reply to Fabiano Fidêncio from comment #3) > Hmm. I was not able to setup my local machine to test it. > However, I've tested against Christophe's machine and didn't have any > problem. > > Can you test with upstream spice-gtk[0]/virt-viewer[1]? If it's not handy > for you, please, give me access to your test machine and I'll try it. > > [0]: Necessary patches from spice-gtk: > 04e2741c687ec9f73f07429202e0d7da9c90cfcf > af3ee8043e2e04a81858e4d4f10df4c26ada9d51 > 0fe5be04ef762a8ae4057f45e64cfdf6ba426102 > fce9201f2f27d90b0224f3dd5845a74e526b5480 > > [1]: Necessary patches from virt-viewer: > 04e02148b29226daca6f9ad96ee4986b7ea3d600 > 69b3096f51bf2b6e9d1606b9fd49499899886ac7 NB: what you have tested on my machine, and what these patches are about is SASL authentication for a SPICE connection. This bug is about a SASL failure when connecting to a remote libvirt daemon as David already pointed out in comment #2. I'm not sure these virt-viewer patches will help with that. (In reply to Christophe Fergeau from comment #6) > ... > NB: what you have tested on my machine, and what these patches are about is > SASL authentication for a SPICE connection. This bug is about a SASL failure > when connecting to a remote libvirt daemon as David already pointed out in > comment #2. I'm not sure these virt-viewer patches will help with that. They do. I tested connection from Fedora 21 client to my machine that has libvirt with sasl and spice without any auth. I didn't test the libvirt+sasl with spice+sasl case though... (In reply to David Jaša from comment #7) > (In reply to Christophe Fergeau from comment #6) > > ... > > NB: what you have tested on my machine, and what these patches are about is > > SASL authentication for a SPICE connection. This bug is about a SASL failure > > when connecting to a remote libvirt daemon as David already pointed out in > > comment #2. I'm not sure these virt-viewer patches will help with that. > > They do. I tested connection from Fedora 21 client to my machine that has > libvirt with sasl and spice without any auth. You have tested that something fixed this issue in f21. If you haven't successfully tested RHEL7 virt-viewer/spice-gtk + only the patches Fidencio mentioned, we can't know for sure if this was fixed by these patches or by something different. Works for me on a RHEL7 with spice-gtk3-0.22-2.el7.x86_64 and virt-viewer-0.6.0-12.el7.x86_64 I'm using qemu+tls://host.example.com/system?no_verify=1 as the QEMU URI, the SASL method used is digest-md5. Try to reproduce this issue with packages:
libvirt-1.2.8-8.el7.x86_64
spice-gtk3-0.22-1.el7.x86_64
virt-viewer-0.6.0-11.el7.x86_64
steps to reproduce:
Environment setup: Prepare 2 hosts: A&B
Assume there is a running guest on remote machine host A
- rhel6_x86_64 running
# virsh list
Id Name State
----------------------------------------------------
2 rhel6.6-juzhou-smartcard running
I. On host A:
1. Edit /etc/sysconfig/libvirtd
LIBVIRTD_ARGS="--listen"
2. Edit /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp=1
auth_tcp="sasl"
3. Add a user named "fred", and setting his password as "redhat"
# saslpasswd2 -a libvirt fred
Password: xxxxxx
Again (for verification): xxxxxx
4. # service libvirtd restart
# service firewalld stop
Redirecting to /bin/systemctl stop firewalld.service
II. On host B:
1. Virsh cmd works with the credentials configured.
# virsh -c qemu+tcp://10.66.4.227/system
Please enter your authentication name: fred
Please enter your password:
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # list
Id Name State
----------------------------------------------------
2 rhel6.6-juzhou-smartcard running
2. Use virt-viewer to connect to guest on host A:
# virt-viewer -c qemu+tcp://10.66.4.227/system rhel6.6-juzhou-smartcard
Result: Authentication box pop up, after input right Username/Password, i can connect to guest on host A.
So i failed to reproduce this issue on old version.
And i cannot hit this issue with new build with same steps above.
spice-gtk3-0.26-3.el7.x86_64
libvirt-1.2.16-1.el7.x86_64
virt-viewer-2.0-3.el7.x86_64
So djasa, please help me have a look of my steps, thanks very much. And what's more, have you also hit this issue with new build.
Yeah, it looks that all the necessary fixes landed already in 7.1 based on my testing of fresh 7.1 system. I'll have to verify with 7.0 as well as I'm fairly sure that it didn't work there. I'm inclined to close as currentrelease. Refer to comment 13 and comment 16,close this bug. Fabiano,would you pls help to remove this bug from erratum,thanks in advance. |