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@xxxxxxxxxx>" 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 -=| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
