Need to know more about Virtualization Restrictions in RedHat Linux?

This guide is for you.

There are a few additional support and product restrictions of the virtualization packages in Red Hat Enterprise Linux 6.

Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to perform Virtualization queries on their servers.

In this context, we shall look into Virtualization Restrictions in RedHat Linux.

Virtualization Restrictions in RedHat Linux

a) KVM hypervisor

The following restrictions apply to the KVM hypervisor:

i. Maximum vCPUs per guest

Depending on the version of Red Hat Enterprise Linux 6 we use as a host, the maximum amount of virtual CPUs support per guest varies.

While the release of 6.0 has a maximum of 64, the 6.3 has a maximum of 160. As of version 6.7, it supports a maximum of 240 virtual CPUs per guest.

ii. Constant TSC bit

Our CPU has a constant Time Stamp Counter if the constant_tsc flag is present.

We can determine if our CPU has the constant_tsc flag:

$ cat /proc/cpuinfo | grep constant_tsc

If we have an output, the CPU has the constant_tsc bit.

However, systems without a Constant Time Stamp Counter require additional configuration.

iii. Virtualized SCSI devices

SCSI emulation does not support KVM in Red Hat Enterprise Linux.

iv. Virtualized IDE devices

KVM limits to a maximum of four virtualized IDE devices per guest virtual machine.

v. Migration restrictions

Since device assignment uses hardware on the specific host where the virtual machine runs, migration as well as save/restore do not support when it is in use.

If the guest operating system supports hot-plugging, assigned devices can remove prior to the migration or save/restore operation to enable this feature.

Live migration is only possible between hosts with the same CPU type.

For live migration, both hosts must have the same value for the No eXecution (NX) bit, either on or off.

Similarly, for migration to work, cache=none must specify on all block devices open in write mode.

Generally, failing to include the cache=none option can result in disk corruption.

vi. Storage restrictions

There involve risks if we give guest virtual machines write access to entire disks or block devices.

If they have access, they can share any volume label or partition table with the host machine.

In addition, if bugs exist in the host system’s partition recognition code, this can create a security risk.

We can avoid this by configuring the host machine to ignore devices assigned to a guest virtual machine.

vii. Core dumping restrictions

Core dumping uses the same infrastructure as migration and requires more device knowledge and control than device assignment can provide.

Therefore, it does not support when device assignment is in use.

b) Application Restrictions

Certain aspects of virtualization make it unsuitable for certain types of applications.

Applications with high I/O throughput requirements should use the para-virtualized drivers for fully virtualized guests.

However, without them, certain applications may be unpredictable under heavy I/O loads.

We should avoid the following applications due to high I/O requirements:

i. kdump server

ii. netdump server

Generally, we carefully evaluate applications and tools that heavily utilize I/O.

We can consider para-virtualized drivers or PCI device assignments for increased I/O performance.

The performance benefits of virtualization should be evaluated against the potential application performance issues associated with using virtualization.

[Find this guide helpful? Get support now. ]