Installation guide
Overcommitting guests by swapping out temporarily unused guest memory can be very slow, due to
the IO latency introduced by disk seek times. However, Red Hat Enterprise Linux virtualization with
KVM can often avoid this disk IO penalty by merging multiple pages with identical content into the
same physical pages. This is done by the KSM (Kernel Samepage Merging) kernel process, which
scans memory to find identical pages. The KSM kernel process uses CPU time to avoid disk IO. This
tradeoff is often beneficial in workloads with many smaller, similar guests.
It is possible to run with an overcommit ratio of ten times the number of guests over the amount of
physical RAM in the system. This only works with certain application loads (for example desktop
virtualization with under 100% usage). Setting overcommit ratios is not a hard formula, you must test
and customize the ratio for your environment.
O verco mmit t in g virt u aliz ed CPU s
The KVM hypervisor supports overcommitting virtualized CPUs. Virtualized CPUs can be
overcommitted as far as load limits of guests allow. Use caution when overcommitting VCPUs as
loads near 100% may cause dropped requests or unusable response times.
Virtualized CPUs are overcommitted best when each guest only has a single VCPU. The Linux
scheduler is very efficient with this type of load. KVM should safely support guests with loads under
100% at a ratio of five VCPUs. Overcommitting single VCPU guests is not an issue.
You cannot overcommit symmetric multiprocessing guests on more than the physical number of
processing cores. For example a guest with four VCPUs should not be run on a host with a dual core
processor. Overcommitting symmetric multiprocessing guests in over the physical number of
processing cores will cause significant performance degradation.
Assigning guests VCPUs up to the number of physical cores is appropriate and works as expected.
For example, running guests with four VCPUs on a quad core host. Guests with less than 100%
loads should function effectively in this setup.
Important
Do not overcommit memory or CPUs in a production environment without extensive testing.
Applications which use 100% of memory or processing resources may become unstable in
overcommitted environments. Test before deploying.
33.5. Modifying /et c/grub.conf
This section describes how to safely and correctly change your /etc/grub.conf file to use the
virtualization kernel. You must use the xen kernel to use the Xen hypervisor. Copy your existing xen
kernel entry make sure you copy all of the important lines or your system will panic upon boot
(initrd will have a length of '0'). If you require xen hypervisor specific values you must append
them to the xen line of your grub entry.
The output below is an example of a grub.conf entry from a system running the kernel-xen package.
The grub.conf on your system may vary. The important part in the example below is the section
from the title line to the next new line.
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
Chapt er 33. T ips and t ricks
313