As we consider the commonly asked question of OpenVZ vs KVM virtualization, we must discuss the significant contrasts in the way each environment manages storage volumes.
Introduction
By utilizing KVM (kernal-based virtual machines), the server has direct control over it’s own unique kernel, which provides the KVM admin exceptionally greater security and control than OpenVZ.
Additionally, storage volumes in KVM are absolute and no two storage volumes will ever overlap (or claim access to the same storage block). This is contrary to the OVZ/Container, where there is no limit to the number of storage volumes “occupying” the same space. In OVZ, the only way to definitively declare exclusive access to the storage is to write it. While the block is filled, it belongs exclusively to the VM that filled it.
READ ALSO: OpenVZ vs. KVM VPS
Why does this distinction matter?
Simply put, any storage volumes in OVZ are hypothetical and the host machine quite possibly may not be able to fulfill it’s original promise, due to making the same empty promises to multiple other VMs without regard to fulfillment of said promises.
This does not mean that other checks and balances cannot be integrated into the OVZ host that would be able to limit the OVZ host’s compulsions to over-promise, but it is certainly beyond the OVZ VM’s jurisdiction. As a VPS-level admin, this may not seem like an important distinction to all, but to many VPS admins, this significant compromise forfeits the stability they require from their servers and will be a deal-breaker.
Conversely, the KVM host node is unable to promise any storage volume that it cannot deliver. In OVZ, any block that is not written is fair game for any VM who will write it. In KVM, any volume allocated to a user is removed from the available storage pool and treated as if it were no longer available (even if this volume is completely empty).
Node Admins Will Have A Different Perspective
As a Host Node administrator, containerized virtualization has a very different outlook. This provides the administrator with greater possibilities and also could be considered more stable, due to the forgiving nature of it’s laissez-faire storage management policies. The very same architecture that causes unreliability for the VM admin becomes the Host Node admin’s greatest ally, should a volume become full. The Host Node admin can easily extend the volume with unused portions of other VM volumes.
In KVM, the Host Node admin would actually need to resize (shrink) the VM with unused volume prior to giving access to a full VM, since the hypervisor is unable to over-commit (or oversell) storage. Of course, if there is uncommitted storage available on the Host Node, then this process is not necessary.
This is a very specific scenario, but this would demonstrate at least one situation where the Containerized environment had a competitive advantage over the Kernel-based environment. There are actually a number of features of Container-based virtualization that might be considered favorable over the KVM virtualization environment for Host Node admins.
The opposite is almost always true for VPS admins, however, and it is advisable to seek out KVM VPS servers whenever possible for VPS hosting.
