Linux - Virtualization and CloudThis forum is for the discussion of all topics relating to Linux Virtualization and Linux Cloud platforms. Xen, KVM, OpenVZ, VirtualBox, VMware, Linux-VServer and all other Linux Virtualization platforms are welcome. OpenStack, CloudStack, ownCloud, Cloud Foundry, Eucalyptus, Nimbus, OpenNebula and all other Linux Cloud platforms are welcome. Note that questions relating solely to non-Linux OS's should be asked in the General forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Well I'm not sure exactly if RHEV-H makes nay further configuration about it, but KVM will allow you to peg certain cores to certain VM's, allowing you to partition off as many cores as you want, which will then be freely contended within each cores permitted guests vms
So, you have an over commit situation. If I understand you correctly, you've created a scenario that requires more cores than what you actually have to give... as expected, performance is going to drop off dramatically (under high loads across all). Virtualization is designed to make effective use of under utilized hardware resources. It's not a miracle maker. Thus if you have 20 guests that aren't used much and a total of 16 cores, things work great if each guest uses one core.
If you have one guest that needs more resources, dedicate more to it. But IMHO, you've created a scenario that doesn't work well.... right? Or am I missing something?
Also, this problem could be worse if those aren't TRUE cores (e.g. Intel Hyperthreads).
First rule of virtualization, start guests off with the minimum resources you can give them. Then examine utilization and bump where needed.