[et-mgmt-tools] [PATCH] use localhost when connecting local VNC guest console

Daniel P. Berrange berrange at redhat.com
Fri Aug 31 18:00:10 UTC 2007


On Fri, Aug 31, 2007 at 06:44:18PM +0200, Bernhard Kaindl wrote:
> Hi,
>    I tried virt-manager-0.5.0 and one of the new features of 0.5.0,
> the support for managing guest on other hosts has resulted in a regession
> where in 0.4.0, the destination port for the VNC connect was 127.0.0.1:5900
> for the local host, while it is now <hostname>:5900:
> 
> What resulted in the regession for me was that I was using libvirtd
> to manage QEMU guests and this setup didn't bind it's VNC port to
> <hostname>:5900, but to 127.0.0.1:5900, where it was expected to be
> with virt-manager-0.4.0.

Ok, I think I understand the situation you're seeing, but just to be sure -you
are running virt-manager directly on the Dom0 box being managed & its using a
'local' libvirt connect URI (ie one without any hostname in the URI).

In Fedora /etc/hosts always has an entry for the qualfied hostname listed
against 127.0.0.1 which'd be why i didn't notice this regression. Obviously
this isn't something we can rely on, so need to explicitly connect to the
localhost

> How it securely connect to the VNC console of other hypervisor hosts
> is over an insecure network is another issue, but it seems easy to
> make the console widget of virt-manager-0.5.0 working with the current
> VNC console setup when checking by using 127.0.0.1 for the hostname:

QEMU now supports TLS + x509 certs in its VNC server. In Fedora I have also
patched the Xen & KVM forks of QEMU to have the same capability, so it is
secure for virt-manager to talk directly to the VNC server across an untrusted
LAN. I will be submitting the KVM & Xen backports of this code upstream in the
near future.  I also intend to make virt-manager able to tunnel VNC over SSH
for scenarios where the VNC server isn't listening publically.

> 
> virtManager's console.py uses get_graphics_console(self) to get the
> directions for connecting to the graphics_console of the guest, so
> as far as I tested yet, that is fixed by checking if
> 
> self.connection.get_hostname()
> 
> 	equals
> 
> self.connection.get_local_hostname():
> 
> and if that is so (both are the hostname of the local machine) then
> the VNC connection can be directed to 127.0.0.1 as before:

Hmm, I think I'll change the get_hostname() method so you can pass a
flag indicating whether it should just return '127.0.0.1' for local
connections, which should have same effect as the patch you provide.

Regards,
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 




More information about the et-mgmt-tools mailing list