[Users] General: Edit Policy

Doron Fediuck dfediuck at redhat.com
Thu Dec 13 16:49:25 UTC 2012


----- Original Message -----

> From: "Jonathan Horne" <jhorne at skopos.us>
> To: "Jonathan Horne" <jhorne at skopos.us>, users at ovirt.org
> Sent: Thursday, December 13, 2012 5:32:17 PM
> Subject: Re: [Users] General: Edit Policy

> ok, so moments after i sent that question, i finally stumble onto the
> RHEV documentation, and it states that the setting is for CPU load,
> and you specify what % and how many minutes its allowed to stay that
> way before no new VMs are allowed to start on the host.

> but still leaves the question, what about memory resources and how
> are they governed as far as automatic migrations go?

> thanks,
> jonathan

> From: Jonathan Horne < jhorne at skopos.us >
> Date: Thursday, December 13, 2012 9:18 AM
> To: " users at ovirt.org " < users at ovirt.org >
> Subject: [Users] General: Edit Policy

> today i just saw for the first time Clusters – General: Edit Policy
> button. i changed it from nothing to balanced. googling, it seems
> that this is for CPU load amongst the hosts to balance the CPU load
> of VMs. the reason I'm asking is, my test environment is 3 hosts,
> and 2 of them are leveled up to above 75% memory usage (both of them
> complaining on the events console), and nothing migrating to the 3rd
> node which currently has 0 VMs.

> do i have something incorrectly configured? i was under the
> assumption that migrations would happen automatically when host
> resourced were nearing max (i assumed this was either CPU or
> memory)? on my cluster, i checked the setting for memory
> optimization for servers.

> is there anything else? am i not properly understanding the migration
> theory? my "guide" link in the upper right does not hyperlink to any
> docs, so I'm left to google and i have not found much so far.

> thanks for any advice,
> jonathan

> This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery. NOTE: Regardless of content, this e-mail shall
> not operate to bind SKOPOS to any order or other contract unless
> pursuant to explicit written agreement or government initiative
> expressly permitting the use of e-mail for such purpose.

> This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery. NOTE: Regardless of content, this e-mail shall
> not operate to bind SKOPOS to any order or other contract unless
> pursuant to explicit written agreement or government initiative
> expressly permitting the use of e-mail for such purpose.

Hi Jonathan, 
Indeed this works for memory overcommitment. 
A ssuming you have ksm running on your hosts , it should share memory pages 
allowing you to do memory overcommitment. Note that currently oVirt has an 
indication for each host if it has shared pages or not, and the relevant percentage 
(Click a host, watch the General sub-tab: "Memory Page Sharing" and "Shared Memory"). 

WRT doing mistakes, we're planning to improve it in the future. but for now, if your sharing 
is poor, the host may start swapping the guests which is not good performance-wise. 

I suggest you give it a try, and watch the statistics, as each OS has its own memory behavior. 
Let me know if you have more questions. 

Doron 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20121213/8efa6dda/attachment-0001.html>


More information about the Users mailing list