SPICE - VNC Connection problems after migrating 2.2 to 3.0
Hi ,
I recently migrated one of my vm from 2.2 to 3.0.
I started the vm successfully but when I try to VNC or SPICE from the RHEV-M I get a dialog saying "Failed to connect to Server " for VNC connections and "Error Connecting to virtual machine using spice: The client could not connect to the remote computer . Remote Connections might not be enabled or a network problem is preventing your connection" for SPICE connections.
I already opened a case for this we,found out that the firewall is not an issue, we turned the iptables service off on the RHEV-M and attempted thte VNC/SPICE connection without success.
Now this problem applies to all vms that I have migrated, I don't know this is happening because of themigration or for some other reason.
Any clues?
thank you
marcello
Responses
Hi Marcello,
Let me make sure I understand the current situation correctly first - you already tested the fact that the VMs are actually started, and you also made sure there are no network issues, right? Have you tested the actual spice/vnc ports while the VM was running, and see that they open and start listening when you kick the VM off? Besides the console, your migrated VMs are working, and are accessible over the network, right?
BTW, when you create a new VM in the same setup, does it have the same issue, or does this affect only the migrated VMs?
Hi,
I am getting these same errors with a new RHEV 3.0 installation. My sense is that it is a firewall problem. Is there a list of ports that I need to have open?
The RHEV-M host is across the WAN in relation to the RHEL host and VM guests.
Thanks,
Paul
And where is the client machine exactly? Thing is, RHEV-M's user and admin portals are connection brokers, not proxies. This means they open a spice/vnc client on the client machine, but the spice/vnc client is not pointed at RHEV-M, but at a port on a hypervisor, that provides the console for a specific VM. So if there's is a NAT between the client machine the the hypervisors, you it can be very hard to get to the console.
What is usually done, is the placing of the Display network (rhevm by default, unless another network is set up for this), in the same network as the clients. Usually it's just the same VLAN, or, if this is a remote setup, the VLAN of the clients dialing in is directly routed to the display network VLAN, with no NAT.
Hi Dan,
thank you for the reply.
My laptop is on the local corporate LAN. The RHEV-M host is also on the local LAN. RHEV-M has a 192.168.x.x address that is NAT from a public IP.
The RHEL virtualization host is remote. It has a public IP address that is NAT to it local LAN 10.x.x.x address.
If I understand your comment, spice is trying to connect my laptop (192.168.x.x) to the address of the RHEVM nic (10.x.x.x) across the WAN.
Paul
Red Hat
Guru
4679 points
Spice will connect your laptop directly to the IP address of the RHEL virtualization host, not RHEV-M. So if your laptop is not able to connect to the 10.x.x.x of your hypervisor directly, spice connection will not work.
First of all the basics: when a VM is running on a host, the host opens a display port for it. When you connect to VNC or spice, you are connecting to a port on the host, not the VM, and not the RHEV-M. Because the host provides the console, you are able to see the VM do POST, and boot.
In a simple network, with no WAN and NAT, what happens is like this
Client connects to RHEV-M and opens a portal on RHEV-M, this is happening between the client and RHEV-M.
In the background RHEV-M is talking to the hypervisor hosts, this is between the RHEV-M and the hosts.
Client clicks the display button, to access a VM console, in a portal on RHEV-M, but what happens here is that the spice or vnc link is set up between the client and a hypervisor host DIRECTLY, RHEV-M is excluded at this point.
In your setup, you are accessing RHEV-M over a LAN, but the hypervisors are remote.
Then you try to see a VM's console, but here you do have a problem, because all of a sudden, your client in the local LAN, and it's trying to directly reach the hypervisors behind a NAT, and the ports are not static, so you cannot simply redirect at the router.
thanks for the info.
I am thinking the best way to solve this for me is to setup to use the VPN on the Cisco PIX. After login to the VPN, I should have a 10.x.x.x address on my laptop which is a tunnel to the remote LAN.
I will need to widen the subnet mask from /28 to /24.
Do you all agree with this approach?
Paul
If this allows for a client machine to reach an arbitrary port on the hypervisors on the display network, then yes. The port is not VERY arbitrary of course, it's a range, documented in the admin guide for RHEV