[one-users] OpenNebula 3.2 need memory and CPU over-commit.
Carlos Martín Sánchez
cmartin at opennebula.org
Fri Feb 10 06:43:00 PST 2012
CPU overcommitment can be set up with the CPU / VCPU attributes. Let's say
you have an 8-core host, and you want to run a max. of 16 VMs, each with 2
CPU = 0.5
VCPU = 2
Unfortunately, OpenNebula doesn't have any equivalent for memory
overcommitment. Maybe we should add a new attribute, VMEMORY, and use the
same idea as with VCPU:
MEMORY: requested host memory
VMEMORY: amount of memory that the VM guest will see
We'd like to hear your thoughts. Would that be enough for your use-case, or
do you have any other suggestion to manage ballooning?
And now, how to force the memory overcommitment: You can edit the host
monitoring script to report the double of the real memory. Multiply by
2 $total_memory in /var/lib/one/remotes/im/kvm.d/kvm.rb
Then execute 'onehost sync' as oneadmin in the front-end. OpenNebula will
update the poll script in the next host monitorization cycle.
Carlos Martín, MSc
OpenNebula - The Open Source Toolkit for Data Center Virtualization
www.OpenNebula.org | cmartin at opennebula.org |
@OpenNebula<http://twitter.com/opennebula><cmartin at opennebula.org>
On Tue, Feb 7, 2012 at 4:25 AM, Maxim Mikheev <mikhmv at gmail.com> wrote:
> Hi Steven,
> Thank you for your answer. Unfortunately for me it has some checks
> (OpenNebula 3.2.1).
> Parameters of a host:
> USEDCPU 230.4
> CPUSPEED 1400
> NETTX 168512869
> HYPERVISOR kvm
> TOTALCPU 6400
> ARCH x86_64
> NETRX 4634446500
> *FREEMEMORY 164233748*
> *FREECPU 6169.6*
> TOTALMEMORY 264610312
> MODELNAMEAMD Opteron(TM) Processor 6272
> USEDMEMORY 100376564
> HOSTNAME s0
> The system has running 4 VM's with total allocation 64 CPUs. and VM
> template with CPU=4 and MEMORY=5000 never started (in the Pending state).
> When I turn of any of other running VM's this VM's immediately start.
> I have seen some old e-mails (2010-2011) which are requested such
> behavior and it was implemented. But I didn't find how to adjust it. I
> would like to turn this feature off or to make to possible make 2x (or
> others) overcommitment.
> Can anyone suggest how to change rules?
> On 02/06/2012 09:55 PM, Steven C Timm wrote:
> Hi Max--
> We are using OpenNebula 2.0 here which does not have any protection on either cpu or memory over-commit.
> When you are running OpenNebula with KVM, at least with opennebula 2.0, it counts not the total amount of memory that the user requested but the amount currently being used by the VM, which is usually less. I don't have direct experience with opennebula 3.2 but the same
> must be possible there.
> -----Original Message-----
> From: users-bounces at lists.opennebula.org [mailto:users-bounces at lists.opennebula.org <users-bounces at lists.opennebula.org>] On Behalf Of Maxim Mikheev
> Sent: Monday, February 06, 2012 7:59 PM
> To: users at lists.opennebula.org
> Subject: [one-users] OpenNebula 3.2 need memory and CPU over-commit.
> Hi Everyone,
> We are using Open Nebula on Ubuntu 11.10. Our VM's usually never use a whole system in the same time. But when they are active they usually require huge amount of computational power.
> OpenNebula has a protection from Overcommitment of memory and CPU. I have a question: How can I manually setup Overcommitment by factor 2 for CPU and Memory?
> Significant amount of memory is helpful for our calculations but all this extra memory is a caches. It means that nothing will be happen if Cache size will be decreased for the VM. The cache can be dynamically scale down by balloon driver which is a default for Libvirt and KVM in Ubuntu.
> It means that I absolutely sure that would like to over-commit memory.
> There are no problem for a processor too. Our calculations took usually several days and one day extra for one VM does not change anything.
> I already used these scheme with over-commitment on Proxmox and it works well.
> Users mailing listUsers at lists.opennebula.orghttp://lists.opennebula.org/listinfo.cgi/users-opennebula.org
> Users mailing list
> Users at lists.opennebula.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users