How do I check KVM against OpenVZ and LXC on a server I already pay for?

You can determine if your environment is KVM, OpenVZ, or LXC by executing systemd-detect-virt or inspecting the /proc filesystem for specific virtualization markers. At Hostna, we manage diverse virtualization layers to ensure workload compatibility, and understanding the underlying hypervisor is critical for kernel-level tuning. Identifying whether you are on a machine with a shared kernel or a full hardware abstraction changes how you approach memory management and process isolation.

Using systemd-detect-virt for Rapid Identification

The most direct method for identifying the virtualization technology on modern Linux distributions is the systemd-detect-virt utility. This tool queries the DMI tables and specific CPUID leaves to determine the environment. If your instance is running on a virtual dedicated server, this command will typically return kvm. If it returns openvz or lxc, you are operating within a containerized environment where the kernel is shared with the host node.

systemd-detect-virt

If the command returns none, it suggests the operating system believes it is running on dedicated hardware resources without a hypervisor layer. However, some cloud environments obfuscate these identifiers. In such cases, checking the DMI system vendor via cat /sys/class/dmi/id/sys_vendor can provide further clarity. KVM environments often show QEMU or Red Hat as the vendor.

Identifying OpenVZ through the Proc Filesystem

OpenVZ is a legacy containerization technology that uses a heavily modified Linux kernel to provide isolation. Unlike full virtualization, OpenVZ exposes specific files in /proc that are not present in KVM or LXC. The most definitive marker is the presence of /proc/vz or the /proc/user_beancounters file. This file tracks various resource limits and consumption metrics for the container.

cat /proc/user_beancounters

Inside this file, you will find parameters such as kmemsize, privvmpages, and oomguarpages. If these fields exist, you are certainly on an OpenVZ system. This is important for database administrators because memory allocation behaves differently here. For example, if you are configuring innodb_buffer_pool_size on an OpenVZ container, the OOM killer may terminate the process if the oomguarpages limit is reached, even if the system appears to have free RAM. This is because OpenVZ often employs a burstable memory model where the failcnt column in /proc/user_beancounters increments when you exceed your committed allocation.

Differentiating LXC from OpenVZ

LXC (Linux Containers) is the modern successor to many containerization concepts, utilizing namespaces and cgroups within the mainline kernel. While it shares the kernel with the host like OpenVZ, it does not use the /proc/vz directory. To verify an LXC environment, you should inspect the environment variables of the init process at PID 1.

cat /proc/1/environ | tr '' 'n' | grep container

On most LXC deployments, this will yield container=lxc. Additionally, you can check for the presence of the /dev/lxc directory or inspect the /proc/self/cgroup file. If the cgroup paths contain lxc or docker, you are inside a container. This distinction is vital for security auditing, as LXC containers typically offer better integration with modern kernel security features compared to older OpenVZ versions. When deploying a Linux-based virtual environment, knowing these boundaries helps in setting appropriate cgroup memory limits to prevent one process from impacting the entire node.

Confirming KVM and Hardware Emulation

KVM (Kernel-based Virtual Machine) provides full hardware emulation, meaning the guest runs its own independent kernel. This allows for features that containers cannot support, such as loading custom kernel modules or running non-Linux operating systems. A reliable way to confirm KVM is to check for the presence of the virtio drivers, which are used for high-performance I/O in virtualized environments.

lsmod | grep virtio

Furthermore, you can use dmidecode to pull the system product name. This tool reads the Desktop Management Interface (DMI) table, which is populated by the hypervisor during the boot process. On our platform, we ensure these identifiers are accessible for troubleshooting purposes. A regional infrastructure node running KVM will often identify itself clearly in the DMI data.

dmidecode -s system-product-name

If the output includes KVM, QEMU Virtual Machine, or Standard PC (i440FX + PIIX, 1996), you are on a KVM-based system. This full isolation means that a PHP-FPM pool with pm.max_children = 10 and a 512M memory_limit can claim 5GB in the worst case, which is why a 4GB machine that looks idle can still be killed by the OOM killer during one traffic spike — the ceiling is max_children x memory_limit, not average usage. In KVM, this memory is managed entirely by the guest kernel.

Checking for Nested Virtualization

A common requirement for developers is running containers or virtual machines inside their already virtualized server. This requires nested virtualization to be enabled. To check if your KVM instance supports this, you must look for specific CPU flags: vmx for Intel processors or svm for AMD processors.

grep -E 'vmx|svm' /proc/cpuinfo

If this command returns no output, the hypervisor has not passed through the hardware virtualization extensions to your guest. This is a common configuration on shared infrastructure to maintain stability. If you require these extensions, you may need to move to a plan that provides them, as explained in our technical documentation section. You can also verify if the /dev/kvm device node exists, which is required for the guest to act as a host for further virtualization.

ls -l /dev/kvm

Interpreting CPU Steal Time

Regardless of the virtualization type, the performance of your server can be affected by the host’s load. CPU steal time is the amount of time the virtual CPU waits for the physical CPU while the hypervisor is servicing another processor. You can monitor this using the top or vmstat command. In top, look for the %st value in the CPU summary line.

vmstat 1 5

In the vmstat output, the last column st represents steal time. If this number is consistently high, it indicates contention for physical CPU resources. On a KVM system, this might suggest the host is oversubscribed. On OpenVZ, the impact of other containers is often more direct because they share the same process scheduler. Understanding these metrics is part of the legal framework of resource allocation on any multi-tenant platform. While we strive for optimal resource distribution at Hostna, monitoring these values helps you determine if a performance bottleneck is internal to your configuration or external to the hypervisor.

For more details on how KVM handles these processes, you can refer to the Kernel-based Virtual Machine documentation. For database-specific tuning that takes these virtualization layers into account, see the database configuration guidelines provided by the MariaDB community. If your identification attempts fail or return conflicting results, provide the output of dmesg | grep -i hypervisor and journalctl -k | grep -i virt when contacting technical support for a deeper audit of your environment.

This article was drafted with AI assistance from Hostna’s own research pipeline and published without individual review. Tell us if anything here is wrong.