BACKGROUND IMAGE: stock.adobe.com
The open source nature of Linux and KVM mean that administrators must be particularly cautious about just what build characteristics are deployed.
For example, it's generally recommended to use the same KVM module version that shipped with the rest of a distribution -- this is particularly relevant when you use a standardized distribution, like Red Hat Enterprise Linux (RHEL) or SUSE Linux Enterprise Server (SLES). This provides a known and proven combination of Linux components that has been tested extensively.
While it's certainly possible to replace the canned KVM module with a newer or modified KVM version, any changes will introduce risk to the build, which is highly undesirable in any production environment. Organizations should test any changes thoroughly --- such as testing with a nonessential workload -- before deploying a modified build into production, and should have a rollback plan ready to go if anything goes wrong.
There are also several KVM behavioral characteristics worth noting. KVM uses Intel VT-x and AMD-V x86 processor extensions for virtualization. Non-x86 processors use hardware emulation for virtualization. This can impact the choice of server hardware where KVM is deployed.
KVM allocates memory to the VM as a guest uses it, and then keeps that memory for the guest. Only Linux guests can take advantage of memory ballooning. Same page merging -- Kernel Same-page Merging or KSM -- is available in some host versions, such as RHEL 5.4, so it's important to verify whether your kernel version supports KSM. KVM is capable of offline or live migration, allowing the KVM guest VM to move and continue running on another host system, including moving to and from AMD and Intel host systems.
From a security standpoint, KVM can manage access control to prevent interaction between VMs. These features make Linux -- and KVM -- more attractive for busy enterprise environments.
KVM also supports a broad range of guest OSes, including Windows, Fedora/Red Hat variations, Ubuntu/Debian variations, BSD variations, Solaris/OpenSolaris variations and other Linux OSes, such as Android, SLES, Gentoo Linux, Mandrake Linux and others. This wide support makes the KVM module attractive for mixed workload environments, where many different OSes and workloads must share common hardware resources.
Beyond supporting everyday Linux and other OS workloads, KVM has gained attention in the cloud. For example, KVM is the default, and most commonly used, hypervisor with OpenStack for organizations developing private cloud environments.
Both KVM and OpenStack are open source projects, leading to a level of mutual development interest, especially for service providers that benefit most from the scale and savings of open source software. Ongoing development should eventually improve the range of processor support to embrace ARM, POWER, System z and graphics processing units.
But the KVM module is also receiving more attention in the area of network function virtualization (NFV). Rather than creating and configuring networks using dedicated hardware, network components like switches and firewalls can be implemented as VMs. Instead of configuring each discrete network component manually, NFV components can be configured and managed through software to allow for flexible and easily reconfigured network implementations. This offers yet another major bonus to larger cloud businesses, like service providers.