1:06 p.m.
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
1:09 p.m.
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
1:24 p.m.
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 :|
4:43 p.m.
On Tue, 2014-03-25 at 18:24 +0000, 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
4:51 p.m.
On 03/25/2014 05:43 PM, Nathanael D. Noblet wrote:
On Tue, 2014-03-25 at 18:24 +0000, 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
4:42 a.m.
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 :|
3681
days inactive
3682
days old
5 comments
3 participants
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Nathanael D. Noblet