Bug 983088
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> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
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 | |
Target Release: | 3.4.0 | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | virt | |||
Fixed In Version: | ovirt-3.4.0-alpha1 | Doc Type: | Release Note | |
Doc Text: |
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.
|
Story Points: | --- | |
Clone Of: | ||||
: | 986735 1052162 (view as bug list) | Environment: | ||
Last Closed: | 2015-09-25 11:29:11 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 986735, 998192, 1052162, 1078909, 1142926 |
Description
Julio Entrena Perez
2013-07-10 13:18:20 UTC
michal - i think there was some libvirt change making this different than the old spice port ranges (but i could be wrong)? 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? (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. Michal, can you take a look for 3.3 thanks Aic 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 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 (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. (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. (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). 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 Vinzenz, please update doc text, note bug 998192 in 3.2 as well. Worth adding a way how to change this (qemu.conf, firewall) Merged u/s to master as http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=2553d6a0a858f6b5a80dd102735bea7f38db764f Merged to vdsm u/s master branch as http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=5daa7fa3cc710b79e24176c84a525158717d7e91 ovirt 3.4.0 alpha has been released 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 *** Bug 1095163 has been marked as a duplicate of this bug. *** 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 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? 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 After adding to RHEV-M and activating it, the range gets changed to the correct one. Closing the Bugzilla for now. |