Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1457239 - [RFE] Provide "High Performance VM" Profile to ovirt
[RFE] Provide "High Performance VM" Profile to ovirt
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt (Show other bugs)
future
All All
high Severity high (vote)
: ovirt-4.2.0
: ---
Assigned To: Sharon Gratch
Artyom
https://github.com/oVirt/ovirt-site/p...
: FutureFeature, Performance, Triaged
Depends On: 1461476 1481246 1498187 1498465
Blocks: 1571024 1619210 1444998 1457250 1505927
  Show dependency treegraph
 
Reported: 2017-05-31 08:03 EDT by Martin Tessun
Modified: 2018-08-20 07:01 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Previously, it was difficult to configure a virtual machine (VM) to run with high performance workloads via the Administration Portal as it involved understanding and configuring a large number of settings. In addition, several features that were essential for improving the VM's performance were not supported at all, for example, huge pages and IO thread pinning. In this release, a new optimization type called High Performance is available when configuring VMs. It is capable of running a VM with the highest possible performance, with performance metrics as close to bare metal as possible. When the customer selects High Performance optimization, some of the the VMs settings are automatically configured while other settings are suggested for manual configuration.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-20 06:12:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2+
alukiano: testing_plan_complete+
mtessun: planning_ack+
michal.skrivanek: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 77961 master MERGED Add a new 'High Performance' VM type to UI 2017-06-30 09:33 EDT
oVirt gerrit 79578 master MERGED webadmin: add 'optimized for' field to vm/template/pool/v2v general sub tab 2017-07-19 06:48 EDT
oVirt gerrit 80384 master POST core + webadmin: Automatic properties setting for a 'High performance' VM 2017-08-30 07:51 EDT
oVirt gerrit 80593 master POST webadmin: Automatic setting of IO threads for a 'High performance' VM 2017-08-14 07:07 EDT
oVirt gerrit 81658 master POST core + webadmin: Manual properties setting for a 'High performance' VM 2017-09-12 09:23 EDT
oVirt gerrit 81884 master MERGED core + webadmin: 'High Performance' type is supported only for 4.2 2017-09-26 05:30 EDT
oVirt gerrit 81947 master MERGED core: handle controller devices with model='none' in domain xml 2017-09-25 13:22 EDT
oVirt gerrit 81950 master MERGED webadmin: enable high availability for HP VMs 2017-09-19 09:45 EDT
oVirt gerrit 82210 master MERGED restapi: support High Performance VM type for rest api 2017-09-28 05:58 EDT
oVirt gerrit 82523 master MERGED core: support IO+emulator threads pinning for HP vms 2017-10-24 11:01 EDT

  None (edit)
Description Martin Tessun 2017-05-31 08:03:28 EDT
For providing high performance VMs, a new Profile is requested for adding a configuration for this type of VMs.
The idea is to have VMs that have performance metrics as close to bare metal as possible for running huge VMs.

This profile should be able to check available and configured hugepages and run the VM in these Hugepages, if possible.

Initial thoughts on the needed functionality in the High Performance Profile:
- Headless (Serial Console or VNC only)
- Disable Soundcard
- Host CPU passthrough
- Backed by Hugepages (2M or 1G as configured at Hypervisor Boot Time)
- 1 IOThread pinned to the CPU doing the IO on the Host
  alternatively pinned to CPU#0 as this is typically the one.
- emulatorpin should also be pinned to the same CPU(s) as the iothread
- If CPU supports it, forward also the invtsc flag to the VM
- Disable KSM and Ballooning for a cluster running these types of VMs.
- Do vNUMA with appropriate NUMA pinning according to the Host NUMA topology.

This VM will no longer be migratable. For adding this feature another BZ will be opened.
Comment 1 Red Hat Bugzilla Rules Engine 2017-05-31 08:03:37 EDT
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.
Comment 2 Michal Skrivanek 2017-05-31 08:22:31 EDT
profile == a user configurable preset in New/Edit VM dialog in addition to current Server/Desktop
Comment 3 Michal Skrivanek 2017-06-13 09:36:42 EDT
see also https://trello.com/c/MHRDD8ZO
Comment 4 Martin Polednik 2017-07-18 09:46:29 EDT
The hugepages part of the feature is ready in master - please start working on a test plan.
Comment 6 meital avital 2017-09-14 04:58:51 EDT
(In reply to Martin Polednik from comment #4)
> The hugepages part of the feature is ready in master - please start working
> on a test plan.

Sure
Comment 7 Sharon Gratch 2017-10-03 12:15:34 EDT
All issues are in except io + emulator threads pinning which is posted but not merged yet (waiting for code review), so I will mark this bug as MODIFIED so that all other issues will be tested.

Please don't test iothread + emulator threads pinning yet.
Comment 12 Artyom 2017-12-05 06:24:59 EST
Verified on rhvm-4.2.0-0.5.master.el7.noarch
Comment 14 Sandro Bonazzola 2017-12-20 06:12:31 EST
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Note You need to log in before you can comment on or make changes to this bug.