Select Page

Virtualisation started out in the 1960s for mainframe computers as a means to logically divide system resources between different applications simultaneously. Before that, computers could run only one application at a time. Over the years, virtualisation has expanded in its meaning due to the increase in computer performance. Applications evolved from running on mainframes to running in a more distributed manner based on the client-server architecture.

Now, through the use of virtualisation technology, organisations are able to reduce the number of physical servers deployed, as each machine is able to run multiple operating system instances. This way, there can be cost savings on hardware purchase and maintenance.

In this article, we will be comparing two types of virtualisation technology, namely KVM and OpenVZ. Before we do that, let us take a look at both the virtual machine and container technology to better understand how the two types of virtualisation software compare with each other.

What are virtual machines and containers

A virtual machine is a piece of software that is based on computer architectures to emulate a computer system. Virtual machines do not come in just one flavour — there are different types of virtual machines offering different functionalities.

System Virtual Machine

The first type of virtual machine is known as the system virtual machine or full virtualisation virtual machine. It is because they generally emulate existing architectures and come with software components that allow them to support the running of multiple instances of virtual machines on a single hardware. This allows for better utilisation of resources in terms of energy consumption and cost effectiveness. It also provides a platform to run older versions of applications and programs that can no longer run on modern hardware.

In order to create and run such virtual machines, a hypervisor is needed. It can be a software, firmware or hardware that presents a virtual operating platform to the guest operating systems and manage their executions.

There are currently two types of hypervisors in the market.

The first is the type 1 hypervisor, so named because it runs directly on the hardware. Like an operating system, it controls the hardware and manages the hardware resources. In addition, it manages the guest operating systems.

The second is the type 2 hypervisor, also known as hosted hypervisor, as it runs on a pre-existing operating system like the other applications. It abstracts the guest operating systems and runs each of them as a process on the host.

Process Virtual Machine

The second type of virtual machine is the process virtual machine. This type of virtual machine is designed to run programs in a computer-platform independent manner while running in the user space of an operating system.

And this leads us to another type of virtualisation technology, which is known as containers.


Containers are a type of virtual machines that utilise OS-level virtualisation. They do not provide full virtualisation like those of system virtual machines. Instead, they share the kernel of the host operating system and run in the user space just like any other application. Therefore, they are similar to virtual machines with a type 2 hypervisor but are more lightweight since they do not need to manage the underlying hardware.

The reason for the creation of container technology stems from the need to be able to deploy and run one or more applications with all the necessary libraries and configurations in a new system or environment. It is due to the increasingly competitive market where every minute counts and a slower response could cost a company its market share and potential revenue.

However, the process of getting the libraries and configurations done is tedious and sometimes difficult when the system is not connected to the internet. Therefore, the technology industry drew inspiration from the shipping industry to create a solution where libraries, configurations and applications can be pre-installed, completed and packaged for deployment onsite. It is similar to how shipping containers are used to package and transport goods to their destination.

KVM and OpenVZ

Kernel-based Virtual Machine (KVM) is an open-source virtualisation technology that is built into the Linux kernel in 2007.

What the KVM does is to convert Linux into a type 1 hypervisor. As long as the hardware support is available, users can create and run different virtual machines on the system provided they do the following:

  1. Load the core virtualisation module, kmv.ko
  2. Load a processor-specific module such as kmv-intel.ko and kvm-amd.ko
  3. Install an emulator such as QEMU
  4. Download and install drivers


As seen in the above diagram, KVM is a module within the kernel that supports the running of guest operating systems such as Windows, BSD and Solaris.

Next up, we will take a look at OpenVZ.

Like KVM, OpenVZ is a virtualisation technology and also the core of Virtuozzo, a commercial offering by the company of the same name. The foundation of what would become OpenVZ was originally created and released for public testing under the name Virtual Environment in the year 2000. Then, the company, SWsoft, released a containers virtualisation solution called Virtuozzo 2.0 in 2002. It was based on the foundation laid by Virtual Environment and remained as a closed-source product. In 2005, the company launched the project OpenVZ to open-source the core of Virtuozzo. Since then, both OpenVZ and Virtuozzo have been sharing the same code base, taking advantage of the contribution by the open-source community to develop a stable and secure virtualisation solution for Linux.

As shown in the diagram above, the difference between OpenVZ and KVM is that the former utilises OS-level virtualisation to create independent virtual private servers that resemble containers. It relies on the host kernel to provide hardware abstraction and management of the hardware. Because of this shared kernel, only Linux-based operating system can run in a OpenVZ environment.

Now that we have an understanding of the two virtualisation technologies, we will take a look at their pros and cons in terms of the following:

  1. Flexibility
  2. Stability
  3. Performance
  4. Cost
  5. Security

Pros and Cons


Both KVM and OpenVZ offer users the flexibility to create, run and manage virtual machines. However, they do so in different way.

A KVM, being a type 1 hypervisor, can create and run multiple virtual machines with different operating systems. This give users the flexibility of installing different operating systems on a single server or computer. For example, an organisation may want to have a Linux-based environment to run specific applications and a Windows-based environment to run Microsoft or Windows-only applications.

In the case of OpenVZ, there is less flexibility in terms of the type of operating systems it can support, as compared to KVM. Since its kernel is Linux-based and does not come with a hypervisor, it can only run in Linux environment and all its guests have to be Linux-based too. Furthermore, all containers based on OpenVZ share the same kernel version as the host, which can be a problem if each guest requires a different kernel version for compatibility reasons or testing purposes.


Although both KVM and OpenVZ can be used in production environment, KVM is known to be more stable than OpenVZ.

This is due to the segregation of virtual machines by KVM, whereby each virtual machine is treated as a separate running process. As a result, if there is an issue with one of the virtual machines, it can be handled just like any other application or process running on Linux, whereby it will be terminated and any resources it uses will be reclaimed by the host. IT administrators are also able to manually terminate the process from the command line interface. Meanwhile, the rest of the virtual machines will remain unaffected. This is particularly important if the virtual machines are mission or business-critical.

The same cannot be said for OpenVZ containers. Their sharing of the host kernel would mean that if any of the containers causes the kernel to crash, the host and remaining containers may crash together. In a production environment, this can potentially be a major problem as it can disrupt business operations in the event of application failures or data losses.


The KVM converts Linux into a type 1 hypervisor. As we have seen earlier, unlike the type 2 hypervisor, a type 1 hypervisor runs directly on top of the hardware without having to deal with the operating system or drivers. This gives KVM a higher performance, making it highly suited for enterprise use.

In addition, closeness to the hardware means that I/O intensive applications can be installed in KVM guests and still perform with minimum issues.

However, an individual OpenVZ container can run faster than a KVM guest because of the lack of hypervisor overhead as it relies on the host kernel for all system and hardware-related calls.

That said, the ability to launch multiple container instances with relative ease could put the host system at a high risk of being over-committed. When that happens, it could cause the performance of the host and all guests to suffer since there would not be sufficient resources available.

Over-committing of resources can also happen with KVM but it takes more effort to do so. In order to create and configure a new virtual machine, the service provider or owner of the server need to determine how much memory, CPU and storage space to give to the new guest.


In order to support the running of multiple KVMs, the host needs to have powerful hardware such as faster processors with more cores, as well as higher RAM and secondary storage capacity. Otherwise, applications running in the guests and the host may not be able to function or service any request. The virtual machines and host may even crash during high loads.

Furthermore, if there is a need to run Microsoft Windows, there is a need to purchase licenses.

OpenVZ containers, on the other hand, is able to run on top of an existing operating system and share the host resources with minimal impact on the host’s performance. Each instance is treated like any other application in the system and resources not used by it will be allocated to other parts of the host system or other container instances. Hence, it could run on most computer or laptops with decent amount of processor speed, memory and storage space.

And since OpenVZ containers can only run Linux-based operating systems, there is virtually no cost related to software licensing.


KVM is generally secure because it is part of the Linux kernel. There is no need for a separate module or process to patch the KVM component since the open source community will patch and update the kernel that will ultimately be part of future operating system updates.

In addition, the KVM hypervisor runs directly on the hardware without a host operating system. With that, it does not need to deal with security flaws and vulnerabilities endemic to operating systems as found with type 2 hypervisors.

Furthermore, KVM can be protected by sVirt. It is a security technology based on SELinux, which labels each VM image and start the VM with the label. With that, the VM can only interact with processes, files and/or devices that have the same label. This way, VMs cannot read or manipulate files belonging to the host or other VMs, even if the VM is running as root user.

Lastly, since each VM instance is running an entire operating system, users of these VMs will have isolated environments since the operating systems have their own kernel and do not have visibility of the files and data belonging to their neighbours. Moreover, firewalls and anti-malware tools can also be installed on each to ensure malicious applications or malware do not take advantage of the virtual network and spread themselves. Also, if the guest operating system is Linux-based, it could also have SELinux enabled and running.

OpenVZ containers are relatively secure because it is based on the Linux kernel, specifically the Red Hat Enterprise Linux kernel. The OpenVZ team tracks and analyses security updates to the Linux kernel. Then, they will apply the updates accordingly to ensure OpenVZ is secure. SELinux can also be installed and enabled on the host to protect it and its various application and processes.

However, due to the way the containers modify the host kernel, they cannot install or run SELinux. They are also not completely safe from attacks that are directed at the host. Any vulnerabilities in the host kernel will affect the OpenVZ containers. And if the host operating system ever goes down, all the running container instances will go down with it.


Both OpenVZ and KVM are mature virtualisation technologies, have their respective purpose and serve different market needs. They have seen use in many enterprise environments.

Even though OpenVZ is the winner in terms of CPU performance, KVM offers a better overall performance. Furthermore, OpenVZ is at a disadvantage when there is a need for better stability and flexibility to run non-Linux operating system in virtual machines.

KVM provides the flexibility to support different type of operating system as guests, thus making it a more compelling option. And with sVirt, KVM is also safer and more secure for users who need to process sensitive information since the technology ensure each VM can only work with files or resources that have the same label.