SPICE - listening ports

Latest response

 

Hi,
 
# virsh -r list --all
 Id    Name                           State
----------------------------------------------------
 1     se06inpidaydb1                 running
 2     se06inpinfapp1                 running
 
# netstat -tulpn |grep :59
tcp        0      0 0.0.0.0:5900                0.0.0.0:*                   LISTEN      11566/qemu-kvm
tcp        0      0 0.0.0.0:5901                0.0.0.0:*                   LISTEN      11566/qemu-kvm
tcp        0      0 0.0.0.0:5902                0.0.0.0:*                   LISTEN      11638/qemu-kvm
tcp        0      0 0.0.0.0:5903                0.0.0.0:*                   LISTEN      11638/qemu-kvm
 
 
 
Every VM seem to spawn two ports for spice connections.
I guess my source adress must be able to communicate with both ports for the VM console to work?
Will it always be 2 spice ports per VM?
Would be good to know since then I know the port range that needs to be opened.

Responses

What the hell happend with the formatting? 

Hej Pär,

Unfortunately using the interface can be a bit challenging.  You may be able to still edit your first post.  If so, try clicking on "Source" and inserting your update there and then click save.  I think all of us have been through the process of discovering how the tool messes up our posts sometimes.

Hey Pär, sorry about that. You can follow James' instructions or email me with the proper formatting if you like and we can clean it up for you. I'm at hhutton@redhat.com.

We're working on a new interface that should help with these formatting difficulties, so stay tuned...

If I click "edit" I can't see the text at all, and switching to source just gives me a ton of text. Will do my best.

I would if I still had it.

Like this?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Hi, 

# virsh -r list --all
Id    Name                           State
----------------------------------------------------
1     se06inpidaydb1                 running
2     se06inpinfapp1                 running

# netstat -tulpn |grep :59
tcp        0      0 0.0.0.0:5900                0.0.0.0:*                   LISTEN      11566/qemu-kvm
tcp        0      0 0.0.0.0:5901                0.0.0.0:*                   LISTEN      11566/qemu-kvm
tcp        0      0 0.0.0.0:5902                0.0.0.0:*                   LISTEN      11638/qemu-kvm
tcp        0      0 0.0.0.0:5903                0.0.0.0:*                   LISTEN      11638/qemu-kvm

Every VM seem to spawn two ports for spice connections.I guess my source adress must be able to communicate with both ports for the VM console to work?
Will it always be 2 spice ports per VM?
Would be good to know since then I know the port range that needs to be opened.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Spice requires two ports, one for the encrypted channels and one for the unencrypted traffic. The range is predefined for you in the host iptables and is mentioned in the RHEV guides as well.

Back to the question:

 

Info about port ranges can be found here:

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html/Administration_Guide/Virtualization_Host_Firewall_Requirements1.html

 

IIRC, for each process an unsecure and a secure port is opened.

5634 - 6166 is a lot of ports. And when is ports below 5900 used?

My mistake! I posted RHEV documentation, but I guess you are using KVM on RHEL?

No, I use RHEV. Sorry for the confusion. Dropped to support shell and ran those commands.
It's a RHEV hypervisor.

"5634 - 6166 is a lot of ports. And when is ports below 5900 used?"

 

I'm not sure how the mechanism of selecting ports works and I can't find any documentation at RHN that explains this, but I have some virtual machines running at ports lower than 5900. So somehow ports below 5900 do get assigned.

How the ports are selected doesn't really matter here. The spice port range is 5634-6166, that's 532 ports, which means you can have 266 VMs there without changing the port range. If you use VNC, you can have double, because VNC only uses a single port.

I suppose you are looking into a NAT solution for spice in your environment, if you are asking about ports, and generally speaking, port forwarding will not work here- the range is wide and dynamic, and there are better, more secure solutions.

Not looking into a NAT solution. Just trying to minimalize the number of open ports between networks.
Feels wrong to open 532 ports when I know that we will probably never run more than 10 VMs on a hypervisor.
If it would always start from 5634 and then 5635 etc it would be easier to open the correct amount of ports instead of open 532 of them.

I would set up a separate display network and open only the spice ports on that, and then put the interface in the user network VLAN. This way, firewall or not, there will be nothing listening unless a VM is started, and when a VM is started, you want those ports open after all

Instead of opening ports, why not have remote SPICE clients VPN into the RHEV network?  Or another idea - I wonder if anyone from the Netfilter team is following this discussion and would be willing to put together a SPICE conntrack module?

for additional security, VPN them into the display network, leaving rhevm out

 

as for conntrack, that's an interesting idea, but it has to make it upstream first

SPICE works via iptables NAT. I had a partial solution in place where split-brain DNS would point all hostnames of Hypervisors to a singular IP (Linux router) which would then forward on the ports. This doesn't work with more than one Hypervisor though since the port ranges clash. If the Hypervisors had exclusive port ranges, this could become a viable solution for users connecting from over the WAN - and would cut down on the latency added by any VPNs. Only other ways I can think of are Public IPs for each Hypervisor, or VPN into the Display subnet.

Talking of opening a very wide range of ports unnecessarily. How does it matter if the ports are not open on the Host anyway? The purpose of a firewall is to have separate policies (based on a variety of parameters) for ports that may be open, or could be open in the future. Yes, there are frivolities like altering the response type of denied connection.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.