apextrooper
Dabbler
- Joined
- Jul 5, 2014
- Messages
- 10
I would like to report a problem I stumbled on and describe a work around for it.
I just upgraded to a new server that is capable of supporting bhyve virtual machines. This server has four NICs and all are connected to a managed switch. I use my DHCP server to statically assign addresses to each NIC. The first gets xxx.100/24 and the fourth gets xxx.103/24.
FreeNAS 11.2-U4.1 is installed.
The first NIC url is selected in the browser and I set about configuring the system. Everything appears to be very normal. In the mean time I've created a pool and several data sets are now filling up from the old server via rsync.
While the rsync tasks are running I decided to test out the new bhyve VM feature with this new server.
After creating a VM, the VNC option is selected from the summary page. A new browser window is opened for VNC access with a report "Unable to connect to server xxx.100:5929"
I tried the same thing with TigerVNC and I receive a "connection actively refused message". It seems that the port is not in use or blocked.
The root cause of the problem is that the VNC client port is established on the bind address in the create sequence. By default this appears to be selected as bge0, *NOT* on the connection used for the current GUI connection. In this case bge0 happens to be xxx.102.
The bind address appears in the VM create wizard but so far I have not found it elsewhere. It is easy to overlook.
FreeBSD assigns the network name in the order it finds them, not the order which is not the same as the NIC numbers found on the equipment back plate.
The work around is changing the url in the VNC tab to xxx.102:5929 and the VNC connection completes properly. The same address works for the TigerVNC connection too.
So the work around is to remember the bind address and use it for the network address for GUI access or change the VNC address to the bind address. But so far it appears that this setting must be manually remembered!
I call this a work around and not a solution because it appears to be a bug and not a feature. It is OK that the VNC port is not on the GUI port, but when the VNC browser tab is opened, it must be opened with the correct uri for the selected VM. It might be a great feature to advertise the VNC uri on the VM summary page even if it cannot be changed. It would save a few hours of searching for why things don't work!
I just upgraded to a new server that is capable of supporting bhyve virtual machines. This server has four NICs and all are connected to a managed switch. I use my DHCP server to statically assign addresses to each NIC. The first gets xxx.100/24 and the fourth gets xxx.103/24.
FreeNAS 11.2-U4.1 is installed.
The first NIC url is selected in the browser and I set about configuring the system. Everything appears to be very normal. In the mean time I've created a pool and several data sets are now filling up from the old server via rsync.
While the rsync tasks are running I decided to test out the new bhyve VM feature with this new server.
After creating a VM, the VNC option is selected from the summary page. A new browser window is opened for VNC access with a report "Unable to connect to server xxx.100:5929"
I tried the same thing with TigerVNC and I receive a "connection actively refused message". It seems that the port is not in use or blocked.
The root cause of the problem is that the VNC client port is established on the bind address in the create sequence. By default this appears to be selected as bge0, *NOT* on the connection used for the current GUI connection. In this case bge0 happens to be xxx.102.
The bind address appears in the VM create wizard but so far I have not found it elsewhere. It is easy to overlook.
FreeBSD assigns the network name in the order it finds them, not the order which is not the same as the NIC numbers found on the equipment back plate.
The work around is changing the url in the VNC tab to xxx.102:5929 and the VNC connection completes properly. The same address works for the TigerVNC connection too.
So the work around is to remember the bind address and use it for the network address for GUI access or change the VNC address to the bind address. But so far it appears that this setting must be manually remembered!
I call this a work around and not a solution because it appears to be a bug and not a feature. It is OK that the VNC port is not on the GUI port, but when the VNC browser tab is opened, it must be opened with the correct uri for the selected VM. It might be a great feature to advertise the VNC uri on the VM summary page even if it cannot be changed. It would save a few hours of searching for why things don't work!
