Red Hat Bugzilla – Bug 1255474
[RFE][SCALE] traffic shaping on ovirtmgmt interface
Last modified: 2017-09-28 04:19:32 EDT
Sharing the same interface for VM networks, management and migrations(and display, and storage) is discouraged, yet common.
Overloading the single interface by e.g. mass migration or a peak in VM activity causes serious issues with engine-vdsm communication. We see timeouts, problems in monitoring, eventually causing non-responsiveness of the host which causes even worse issues.
In order to keep management working we should employ traffic shaping to guarantee some bandwidth is always available to vdsm
this is part of the overall migration improvement effort tracked by bug 1252426 (hence 4.0 timeframe)
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
rhev-3.6 features host network QoS (bug 1043226). with it, customers can manually set their own capping on migration network. As far as I understand, this RFE tracks setting up a magical good policy by default.
(In reply to Dan Kenigsberg from comment #5)
> rhev-3.6 features host network QoS (bug 1043226). with it, customers can
> manually set their own capping on migration network. As far as I understand,
> this RFE tracks setting up a magical good policy by default.
yes, magic default QoS for management network to make sure heartbeats and essential communication works at all times
Meni, could you define a mgmt network with QoS (link share, later abs limit) and then define another network with no QoS on the same nic via vdsm API (as Engine blocks this config). Then, repeat on another host, and stress-test the host-to-host communication with two concurrent iperfs (each per network).
Please report the throughput of each network for each QoS flavour.
Assuming we can drop the Engine-side validation of QoS and non-QoS networks on the same NIC, this would be doable.
Applying QoS on the management network by default may have serious impact on host CPU. We need to measure that before applying it to most users.
Gil, can we find the time to do that?
clearing needinfo, as mburman reports no distinguishable effect of performance.
I suggest to set the default QoS on a network whenever it is assigned with the management role.
To properly implement this RFE, we'd need to set a QoS on each cluster's management network. Since the network is a DC entity (until http://www.ovirt.org/feature/remove-dc-entity-network/ is implemented ) setting its QoS on one cluster may put other clusters' hosts into out-of-sync.
This is a bit ugly, but may amended by the user clearing the default QoS or applying it on the other clusters as well.
This feature currently has no meaning. we depend on BZ - 1346318