Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Virt-manager throws a parsing error when trying to connect to a remote host using SSH where the username is a Windows domain username (e.g. domain\username or username). Version-Release number of selected component (if applicable): 1.4.0 How reproducible: Every time Steps to Reproduce: 1. Create a new connection in Virtual Machine Manager 2. Select SSH under Method 3. In username, put domain user name (e.g. lan\david or david.com) 4. Put in hostname 5. Connect Actual results: Immediate error message Expected results: Connect to server Additional info: Error message displayed: Unable to connect to libvirt. internal error: Unable to parse URI qemu+ssh://lan\user-example@computername/system Verify that the 'libvirtd' daemon is running on the remote host. Libvirt URI is: qemu+ssh://lan\user-example@computername/system Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 904, in _do_open self._backend.open(self._do_creds_password) File "/usr/share/virt-manager/virtinst/connection.py", line 148, in open open_flags) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: internal error: Unable to parse URI qemu+ssh://lan\user-example@computername/system
Thanks for the report. Can you try replacing the \ with %5C and see if it works? If not, please post the error
That seemed to work. It let me continue and put in the password, but fails with authentication unavailable: no polkit agent, which I believe to be a misconfiguration on my part
It worked. Thank you for the assistance.
Unfortunately, there is a follow up. When trying to open a VM it attempts to use %5C in the credentials (e.g. lan%5Cuser) and fails each time
Can you post the virt-manager --debug output when reproducing that error as well? Note, virt-manager should be changed to handle this URI escaping automatically, I'm just trying to get the full picture
Created attachment 1284176 [details] Virt Manager debug log
I have attached the debug log as requested. During this debug I went through both sets of errors: the initial one where it fails to connect and the second one where it fails to open up the VM viewer because it's trying to authenticate with the %5C in the username
Thanks for the info. I pushed this commit which hopefully fixes things: commit 1d0b4a0a9e754a3d0d4da17ca88a0be29107ff5e (HEAD -> master, origin/master, origin/HEAD) Author: Cole Robinson <crobinso> Date: Thu Jun 1 14:14:49 2017 -0400 connect: Handle \ in username We need to quote URL values in the username, that's what libvirt expects. Unquote the values before caching them in the URI object, so console connections continue to work https://bugzilla.redhat.com/show_bug.cgi?id=1452389 Can you give it a test? git clone git://github.com/virt-manager/virt-manager cd virt-manager ./virt-manager --debug
Created attachment 1284249 [details] Virt Manager Debug log 2
I have attached the new logs. It automatically substituted the '\' for '5%C' and never authenticated, just hung on connecting
Hmm that doesn't tell me much unfortunately. Does it work with virsh? virsh --connect qemu+ssh://mwat%5Cusername@kvmtest/system
Virsh connects correctly in that format 'virsh --connect qemu+ssh://mwat%5Cusername@kvmtest/system' As an aside, I ssh in using by escaping the slash (e.g.) 'ssh mwat\\username@kvmtest'
Hmm, so the hang happens at connection open time? Have you had virt-manager work with ssh without a \ in the name? If you use virt-manager --debug the password prompt will show up on virt-manager stdout, it won't launch an ssh password dialog (for a bunch of confusing technical reasons)
Virt-manager has never worked with the sole exception of the 5%C you provided
Sorry for the late response. Not sure what the issue is with this. With latest virt-manager code, can you - add a new connection with the \ in the username - add a new connection with the %5C in the username verify that the %5C method works for opening the connection, and the plain virt-manager method fails/hangs or whatnot. Then provide the virt-manager --debug startup output at startup, virt-manager will report the saved connection URIs, I want to compare them to see how they differ
Created attachment 1293312 [details] Test with \ and 5%C
I have attached the --debug for the two test cases. I cloned virt-manager from github before running the test. The first test immediately throws and error, and the second one hangs up
Can you reproduce those steps with this debugging patch applied to virt-manager.git, and post the new output: diff --git a/virtinst/connection.py b/virtinst/connection.py index d1f85c8c..686b7c6e 100644 --- a/virtinst/connection.py +++ b/virtinst/connection.py @@ -144,6 +144,7 @@ class VirtualConnection(object): authcb = self._auth_cb authcb_data = passwordcb + logging.debug("OPENAUTH: %s", self._open_uri) conn = libvirt.openAuth(self._open_uri, [valid_auth_options, authcb, (authcb_data, valid_auth_options)],
Created attachment 1305660 [details] Debug with connection.py debug code
As for my most recent reply, I discovered the second test was hanging up because it was pointing to the wrong server, doh!
Okay so it looks like the initial libvirt connection piece _is_ working, but there's still an issue with the graphical connection piece, not turning the %5C back into a \. However that's working for me with virt-manager git. Your output shows you are running a virt-manager that's installed in the system (see if mentioning /usr/share at the beginning). Are you definitely running latest virt-manager.git? Make sure to 'git pull' to get the latest bits, then run ./virt-manager --debug (the ./ at the beginning is critical)
Created attachment 1316384 [details] virt-manager debug logs 2017-8-21 Attached is the new log. I was able to both connect to host and connect to the VM, a first. Trying to delete the VM caused the application to crash however.
Okay if you can connect to both the connection and the VM, I think this bug is fixed. If you can reliably reproduce the 'delete' issue, please file a separate bug