Bug 448714
| Summary: | Remote connection over SSH not working with virt-manager | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Alexander Todorov <atodorov> |
| Component: | doc-Virtualization_Guide | Assignee: | Christopher Curran <ccurran> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Joshua Wulf <jwulf> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.5 | CC: | 142.bugzilla.redhat, abednegoyulo, lcarlon, mbaudier, mhideo, xen-maint |
| Target Milestone: | rc | Keywords: | Documentation |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-04-07 01:41:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I can't reproduce this problem - works fine for me, both to and from a RHEL-5 machine. To a RHEL-5 machine $ virsh --connect xen+ssh://root@pumpkin/ list --all Id Name State ---------------------------------- 0 Domain-0 running 2 f9x86_64 blocked - freeipa shut off - rebootdemo shut off - RHEL51Test shut off - rhel5bug shut off - rhel5fv shut off - rhel5pv shut off - Xen shut off From a RHEL5 machine $ virsh --connect qemu+ssh://root.19.138/system list --all Id Name State ---------------------------------- - rhel4x86_64 shut off - rhel5x86_64 shut off And even to itself $ virsh --connect xen+ssh://root@localhost/system list --all Id Name State ---------------------------------- 0 Domain-0 running 2 f9x86_64 blocked - freeipa shut off - rebootdemo shut off - RHEL51Test shut off - rhel5bug shut off - rhel5fv shut off - rhel5pv shut off - Xen shut off Please verify that the libvirtd daemon is running on the server being connected to, and use lsof to verify it is listening for connections on /var/run/libvirt/libvirt-sock All of the above is correct. virsh --connect works but virtual-manager (the GUI) doesn't work. Changing summary to reflect that. Also libvirtd is listening on the above mentioned socket. Ok, with virt-manager things are a little more complicated. For managing the local instance, we run virt-manager via console-helper, which makes it switch to root. console-helper scrubs all environment variables though, so it won't be able to access your SSH-agent. So if using SSH connections, you want to select 'Run unprivileged' when virt-manager starts up Ahh, this worked (connected at least). However I haven't seen nothing about it in the documentation. Changing component to Virtualization_Guide to request documenting this. Under Administration/Remote management of Virtualized Guests/Remote management with SSH <quote> If you are using virt-manager (the GUI) select the option 'run unprivileged' in order for the remote connection to work. </quote> This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release. I think I have found another solution that should be documented. The original poster may have run virt-manager as a normal user, but authenticated as root. The solution is to make sure that your local machine's root user can ssh to the remote xen server's root account without prompts or passwords. This means adding the remote server's host key to your local machine's /etc/known_hosts or /root/.ssh/known_hosts, and add your local machine's root user's public key to the remote server's root's authorized_keys file. (Actually, I'm pretty sure you don't have to set up password-less login, since virt-manager will happily ask for the password, but it sure makes things easier if you do! I think that just adding the remote host's ssh host key to known_hosts is sufficient to stop this problem from occurring.) I had the very exact description, steps and results as indicated in comment 1. I can confirm the solution on comment 8. I logged in as a normal user but authenticated as root on virt-manager's prompt. Fixed and expanded in build 92. This will be public for 5.5. Chris |
Description of problem: Remote connection over SSH is not working after configuring according to the Virt Guide. Version-Release number of selected component (if applicable): virt-manager-0.5.3-8.el5 libvirt-0.3.3-7.el5 RHEL5.2 How reproducible: Always Steps to Reproduce: 1. Generate ssh key for your desktop user 2. Add the key to /root/.ssh/authorized_keys on the remote host 3. Verify that ssh root@remote-host works without a password 4. In virt-manager create new connection 5. Chose remote tunneling over SSH 6. Type the remote server hostname Actual results: Unable to open connection to hypervisor URI 'xen+ssh://root@redbull/': libvirt.libvirtError virConnectOpenReadOnly() failed Connection reset by peer Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 307, in _open_thread self.vmm = libvirt.openReadOnly(self.uri) File "/usr/lib64/python2.4/site-packages/libvirt.py", line 132, in openReadOnly if ret is None:raise libvirtError('virConnectOpenReadOnly() failed') libvirtError: virConnectOpenReadOnly() failed Connection reset by peer Expected results: a connection to the remote hypervisor is opened Additional info: In my testcase both server and client is the same machine. I used the actual hostname of the machine rather localhost. Same error happens when using 2 separate machines for client and server. I have followed strictly the instructions in Virtualization Guide when setting up the environment.