|Summary:||New VMs use display network ports outside of documented 5634 to 6166 range|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||Julio Entrena Perez <jentrena>|
|Component:||ovirt-engine||Assignee:||Vinzenz Feenstra [evilissimo] <vfeenstr>|
|Status:||CLOSED ERRATA||QA Contact:||Ilanit Stein <istein>|
|Version:||3.2.0||CC:||acathrow, agkesos, chetan, iheim, jentrena, jkt, jraju, lpeer, lyarwood, mavital, michal.skrivanek, pstehlik, Rhev-m-bugs, sbonazzo, vfeenstr, yeylon|
|Target Milestone:||---||Keywords:||Reopened, ZStream|
|Fixed In Version:||ovirt-3.4.0-alpha1||Doc Type:||Release Note|
Previously, VDSM's documented port range for SPICE was 5634 to 6166, but it used libvirt's default range of 5900 to 65535. Consequently, firewalls set according to this range could erroneously block SPICE traffic. Now, VDSM uses the 5900 to 6923 range for SPICE, which allows concurrent running of up to 512 virtual machines using the SPICE console.
|:||986735 1052162 (view as bug list)||Environment:|
|Last Closed:||2015-09-25 11:29:11 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||986735, 998192, 1052162, 1078909, 1142926|
Description Julio Entrena Perez 2013-07-10 13:18:20 UTC
Description of problem: New VMs created after recent upgrade to RHEV 3.2 use network ports for display outside of the documented range [5634 to 6166]. Version-Release number of selected component (if applicable): rhevm-backend-3.2.0-11.37.el6ev libvirt-0.10.2-18.el6_4.5 vdsm-4.10.2-22.0.el6ev How reproducible: Always for new VMs. Already existing VMs keep using ports within documented port range. Steps to Reproduce: 1. Create a new VM. 2. Observe display ports at https://<rhevm>/api/vms/<vm_uuid>/ 3. Actual results: <display> <type>spice</type> <address>10.204.125.31</address> <port>6236</port> <secure_port>6237</secure_port> <monitors>1</monitors> <allow_override>true</allow_override> <smartcard_enabled>false</smartcard_enabled> </display> Expected results: Ports used for display are within the documented port range. Additional info: Please reassign to appropriate component if engine-backend is not the correct component for this bug. LogCollector including RHEV-M, host sosreport and database dump is unpacked and available at http://jentrena-xw8600.usersys.redhat.com/00900799/
Comment 3 Itamar Heim 2013-07-10 19:03:48 UTC
michal - i think there was some libvirt change making this different than the old spice port ranges (but i could be wrong)?
Comment 4 Michal Skrivanek 2013-07-12 11:23:26 UTC
this must have been ancient. Ever since 3.0 we use auto allocation by libvirt which uses 5900-65535. What documentation are you referring to? What is the "old' version they claim it worked in?
Comment 5 Julio Entrena Perez 2013-07-12 11:56:00 UTC
(In reply to Michal Skrivanek from comment #4) > this must have been ancient. Ever since 3.0 we use auto allocation by > libvirt which uses 5900-65535. > What documentation are you referring to? What is the "old' version they > claim it worked in? For example the RHEV 3.2 Installation Guide: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Installation_Guide/Virtualization_Host_Firewall_Requirements1.html 5634 - 6166 TCP Remote guest console access via VNC and SPICE. These ports must be open to facilitate client access to virtual machines.
Comment 7 Andrew Cathrow 2013-07-14 23:38:51 UTC
Michal, can you take a look for 3.3 thanks Aic
Comment 8 Michal Skrivanek 2013-07-15 09:31:59 UTC
Currently it is: 5900 + sequentially allocated ports - 1 per VNC VM, 2 per SPICE VM, all the way up to 65535 Since RHEL 6.4 there is a possibility to configure the range in libvirt so we should use it (bug 772290) I'd suggest to start from 5900 as we do that for several releases already, and stop at 6411 to support 256 VMs with SPICE on one host
Comment 9 Michal Skrivanek 2013-07-18 09:15:40 UTC
are we fine with the change of the range by default to 5900-6411 ? And adjusting docs. It makes a bit more sense now as since RHEV 2.3 we are always starting at 5900 and we surely don't want to see issues for all the other installations
Comment 10 Julio Entrena Perez 2013-07-18 09:21:34 UTC
(In reply to Michal Skrivanek from comment #9) > are we fine with the change of the range by default to 5900-6411 ? And > adjusting docs. It makes a bit more sense now as since RHEV 2.3 we are > always starting at 5900 and we surely don't want to see issues for all the > other installations I already asked the customer, I will provide feedback later today. If you ask me they should be fine since the proposed range is slightly bigger than the documented one and they never had issues with it before, most loaded hosts have 100+ guests.
Comment 11 Andrew Cathrow 2013-07-19 11:24:33 UTC
(In reply to Michal Skrivanek from comment #9) > are we fine with the change of the range by default to 5900-6411 ? And > adjusting docs. It makes a bit more sense now as since RHEV 2.3 we are > always starting at 5900 and we surely don't want to see issues for all the > other installations ACK.
Comment 12 Julio Entrena Perez 2013-07-19 12:34:42 UTC
(In reply to Michal Skrivanek from comment #9) > are we fine with the change of the range by default to 5900-6411 ? Cortal have confirmed 5900-6411 is fine for them (and they could adjust the port range in the future should they need to).
Comment 13 Michal Skrivanek 2013-10-10 10:41:37 UTC
I'd go with 512 VMs, 3 ports/VM (should be good for bigger setups as well as it's unlikely all the VMs will be SPICE+VNC) so we'll have some slack... - also need to address FW setup - ovirt-engine/packaging/firewalld/aio/ovirt-aio.xml.in for AIO and also engine's db for regular hosts
Comment 15 Michal Skrivanek 2013-11-26 08:07:50 UTC
Vinzenz, please update doc text, note bug 998192 in 3.2 as well. Worth adding a way how to change this (qemu.conf, firewall)
Comment 17 Vinzenz Feenstra [evilissimo] 2013-12-05 11:40:46 UTC
Comment 18 Vinzenz Feenstra [evilissimo] 2013-12-05 11:41:49 UTC
Merged to vdsm u/s master branch as http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=5daa7fa3cc710b79e24176c84a525158717d7e91
Comment 22 Sandro Bonazzola 2014-01-14 08:43:00 UTC
ovirt 3.4.0 alpha has been released
Comment 23 Ilanit Stein 2014-02-17 14:27:11 UTC
Verified on ovirt version: ovirt-engine-3.4.0-0.7.beta2.el6.noarch in /etc/libvirt/qemu.conf, these lines exist after hot deploy: remote_display_port_min=5900 remote_display_port_max=6923
Comment 25 Michal Skrivanek 2014-05-12 07:10:26 UTC
*** Bug 1095163 has been marked as a duplicate of this bug. ***
Comment 26 errata-xmlrpc 2014-06-09 14:59:48 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2014-0506.html
Comment 27 Alexandros Gkesos 2015-09-25 09:41:55 UTC
Hello, There was a regression on RHEV-Hypervisor 6.6 - 20150603.0 Display network ports were again 5634:6166. Was it on purpose or a misconfiguration?
Comment 28 Alexandros Gkesos 2015-09-25 11:10:33 UTC
Regression was also found in the latest rhev-hypervisor6-6.7-20150828.0 iptables: [0:0] -A INPUT -p tcp -m multiport --dports 5634:6166 -j ACCEPT qemu.conf: correct parameters but commented out #remote_display_port_min = 5900 #remote_display_port_max = 65535
Comment 29 Alexandros Gkesos 2015-09-25 11:29:11 UTC
After adding to RHEV-M and activating it, the range gets changed to the correct one. Closing the Bugzilla for now.