Bug 1027948 - [RFE] Apply "Enable Memory Balloon Optimization" change right after the confirmation.
Summary: [RFE] Apply "Enable Memory Balloon Optimization" change right after the confi...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: 3.4.0
Assignee: Nobody
QA Contact:
URL:
Whiteboard: sla
Depends On:
Blocks: GSS_RHEV_33_BETA
TreeView+ depends on / blocked
 
Reported: 2013-11-07 13:32 UTC by Amador Pahim
Modified: 2016-02-10 20:15 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-13 17:58:00 UTC
oVirt Team: SLA
Target Upstream Version:

Attachments (Terms of Use)
Sync MoM Policy (132.39 KB, image/png)
2014-01-13 17:57 UTC, Scott Herold 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Description Amador Pahim 2013-11-07 13:32:11 UTC 
"Enable Memory Balloon Optimization" is a cluster level configuration and it is applied only in next Host change to "Up" state. As the change for Up state isn't something regular in a stable datacenter, users need to change Hosts to maintenance and then back to Up again, migrating running VMs during the process, to have the change in balloon configuration applied.
There is an emergency option in vdsClient command which can be used to disable/enable balloon in each host, but vdsClient is not supported and using this method can be painful in large deployments.

Please apply changes in  "Enable Memory Balloon Optimization" option as soon as users click in "OK" on Cluster/Edit/Optimization window.
Comment 1 Scott Herold 2014-01-13 17:57:10 UTC 
Created attachment 849511 [details]
Sync MoM Policy
Comment 2 Scott Herold 2014-01-13 17:58:00 UTC 
There is a workaround in RHEV 3.3 that enables an admin to Synchronize the MoM Policy on a Host by Host basis without the need to place the host into maintenance mode, migrate VMs, remove from maintenance, then migrate VMs again.  See attached screenshot for details.

We will not be moving this to a fully automated policy due to potential overhead and performance degradation from a Disk I/O and other resource perspective.
Note You need to log in before you can comment on or make changes to this bug.