Re: qemu / VNC / vino

2014-03-26 Thread Daniel P. Berrange
On Tue, Mar 25, 2014 at 12:06:31PM -0600, Nathanael D. Noblet wrote:
   If libvirt/qemu-system-x86_64 starts before vino-server (which is
 common since we don't leave the vnc access on all the time). Then vino
 only listens on ipv6 instead of ipv4 and ipv6. At that point no one can
 connect to the workstation over vnc since we are all ipv4 connected.

BTW, the fact that vino finds something listening on IPv4 port 5900, and
then decides to only listen on IPv6 itself is really a bug in vino.
If a IPv4 port is occupied it should not attempt to listen on the very
same port on IPv6. It should pick a new port where both IPv4 and IPv6
are unoccupied.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qemu / VNC / vino

2014-03-26 Thread David King

Hi

On 2014-03-25 12:06, Nathanael D. Noblet nathan...@gnat.ca wrote:

 I'm not sure where the bug is and it isn't really a big bug as much as
I need to be able to tell either vino or qemu-system-x what ports to
use.


You can change the default port which Vino listens on by changing the 
value of the alternative-port GSettings key, and toggling the 
use-alternative-port setting to true. For example, with:


gsettings set org.gnome.Vino use-alternative-port true
gsettings set org.gnome.Vino alternative-port 

Vino should, if it cannot bind a port, try the next one (up to a limit 
of 6000, I think), so if it it does not do that, please file a bug:


https://bugzilla.gnome.org/enter_bug.cgi?product=vino

--
http://amigadave.com/


signature.asc
Description: Digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

qemu / VNC / vino

2014-03-25 Thread Nathanael D. Noblet
Hello,

  So I've found a 'bug'. I have a group of developers who use
vagrant/libvirt to develop against. We use VNC since we are a
distributed team to connect to each other's desktops/workstations for
when we're at the 'huh this makes no sense'.

  If libvirt/qemu-system-x86_64 starts before vino-server (which is
common since we don't leave the vnc access on all the time). Then vino
only listens on ipv6 instead of ipv4 and ipv6. At that point no one can
connect to the workstation over vnc since we are all ipv4 connected.

  I'm not sure where the bug is and it isn't really a big bug as much as
I need to be able to tell either vino or qemu-system-x what ports to
use. 

  Thoughts? What should I look at/report?
-- 
Nathanael

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qemu / VNC / vino

2014-03-25 Thread Cole Robinson
On 03/25/2014 02:06 PM, Nathanael D. Noblet wrote:
 Hello,
 
   So I've found a 'bug'. I have a group of developers who use
 vagrant/libvirt to develop against. We use VNC since we are a
 distributed team to connect to each other's desktops/workstations for
 when we're at the 'huh this makes no sense'.
 
   If libvirt/qemu-system-x86_64 starts before vino-server (which is
 common since we don't leave the vnc access on all the time). Then vino
 only listens on ipv6 instead of ipv4 and ipv6. At that point no one can
 connect to the workstation over vnc since we are all ipv4 connected.
 
   I'm not sure where the bug is and it isn't really a big bug as much as
 I need to be able to tell either vino or qemu-system-x what ports to
 use. 
 
   Thoughts? What should I look at/report?
 

On Fedora 20, /etc/libvirt/qemu.conf allows you to set a port range that
libvirt will allocate for VMs. You can use that to avoid the vino collision.

- Cole
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qemu / VNC / vino

2014-03-25 Thread Daniel P. Berrange
On Tue, Mar 25, 2014 at 12:06:31PM -0600, Nathanael D. Noblet wrote:
 Hello,
 
   So I've found a 'bug'. I have a group of developers who use
 vagrant/libvirt to develop against. We use VNC since we are a
 distributed team to connect to each other's desktops/workstations for
 when we're at the 'huh this makes no sense'.
 
   If libvirt/qemu-system-x86_64 starts before vino-server (which is
 common since we don't leave the vnc access on all the time). Then vino
 only listens on ipv6 instead of ipv4 and ipv6. At that point no one can
 connect to the workstation over vnc since we are all ipv4 connected.
 
   I'm not sure where the bug is and it isn't really a big bug as much as
 I need to be able to tell either vino or qemu-system-x what ports to
 use. 
 
   Thoughts? What should I look at/report?

In /etc/libvirt/qemu.conf you can set  remote_display_port_{min,max}
to control the port range used

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qemu / VNC / vino

2014-03-25 Thread Nathanael D. Noblet
On Tue, 2014-03-25 at 18:24 +, Daniel P. Berrange wrote:

 In /etc/libvirt/qemu.conf you can set  remote_display_port_{min,max}
 to control the port range used

So that is awesome thank you. 

Given that by default virt-manager/libvirt/qemu listens to
127.0.0.0:PORT as opposed to 0.0.0.0:PORT. Should this be filed as a
bug? As in could the default port qemu started on be 6900 instead of
5900 so that this doesn't happen? I realize that 5900 is the standard
vnc port... I'm just wondering if there is a use case where changing
that config breaks anything?

-- 
Nathanael


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qemu / VNC / vino

2014-03-25 Thread Cole Robinson
On 03/25/2014 05:43 PM, Nathanael D. Noblet wrote:
 On Tue, 2014-03-25 at 18:24 +, Daniel P. Berrange wrote:
 
 In /etc/libvirt/qemu.conf you can set  remote_display_port_{min,max}
 to control the port range used
 
 So that is awesome thank you. 
 
 Given that by default virt-manager/libvirt/qemu listens to
 127.0.0.0:PORT as opposed to 0.0.0.0:PORT. Should this be filed as a
 bug? As in could the default port qemu started on be 6900 instead of
 5900 so that this doesn't happen? I realize that 5900 is the standard
 vnc port... I'm just wondering if there is a use case where changing
 that config breaks anything?
 

There was a bug about that in the past, but we rejected changing the default
range. Libvirt and xen and qemu have all used the assumption of starting at
port 5900 for too long, we didn't want to deal with any potential fallout for
something that affects a small number of users, and that nowadays has a manual
workaround.

vino could always be extended to try a little harder/smarter to find a free
port, which libvirt has done for years.

- Cole
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qemu / VNC / vino

2014-03-25 Thread Nathanael D. Noblet
On Tue, 2014-03-25 at 17:51 -0400, Cole Robinson wrote:
 There was a bug about that in the past, but we rejected changing the default
 range. Libvirt and xen and qemu have all used the assumption of starting at
 port 5900 for too long, we didn't want to deal with any potential fallout for
 something that affects a small number of users, and that nowadays has a manual
 workaround.
 
 vino could always be extended to try a little harder/smarter to find a free
 port, which libvirt has done for years.

Yeah I see what you're saying. Just a couple points in favor of changing
qemu/libvirt...

#1) If someone is using a normal desktop and vino finds a collision it
has no way of informing the user. It could find a free port but telling
someone to connect to my host, I have no way of knowing what port it is
using without going into a terminal and looking for listening ports. The
libvirt/qemu would continue to work by default if the default was set to
something else. In qemu.conf and I presume the other backends
libvirt/virt-manager supported. 

#2) In the case where an admin/user wants to have access to the VM host
from a *remote* host. They have to change some configuration since
qemu-system-x86_64 is only listening on 127.0.0.1 not on any external
interface. At this point the admin is not likely configuring this on a
desktop and if they are can specify any port they'd like and should
realize that if they are using vino (or something similar), they have to
use different ports. (Which I would know too - I just didn't know why
qemu was listening on that port when I didn't have any gui up accessing
that host...).

#3) Based on bugs I've seen on gnome I can't see them changing it much.
(I just posted a bug to vinagre/ a vnc/rdp client) which doesn't notify
the user of a password prompt *or* to accept a certificate on SSL
connections. The devs basically said don't use vinagre, use the command
line program that is being used by vinagre. Kinda odd...

So I understand if nothing gets changed but it would be nice if it was
reconsidered. I may not understand all the implications but if the
default local port was configured to not collide. I dunno, I'd enjoy
it. :) Granted I'm enjoying it at the moment anyway. 

Thanks,
-- 
Nathanael

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct