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 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
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
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?
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
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