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

[Daniel P. Berrange]

On Fri, Aug 31, 2007 at 07:00:10PM +0100, Daniel P. Berrange wrote:
> 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.

It should be fixed with this changeset - let me know if there's still
issues

changeset:   586:4ee6526c32cd
tag:         tip
user:        "Daniel P. Berrange <berrange at redhat.com>"
date:        Fri Aug 31 17:31:00 2007 -0400
summary:     Ensure VNC widget always trys to connect to localhost for local connections

Regards,
Dan.
-- 
|=- 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  -=|