Virtualization shoot-out: Red Hat Enterprise Virtualization

Red Hat's server virtualization solution mixes ease and scalability with a few odd limitations

1 2 3 4 Page 2
Page 2 of 4

Once installed, each RHEV Hypervisor host is given the RHEV Manager IP address and checks in. Within the management interface, you then allow the host to participate and get started with the configuration. This process is certainly quick and easy, but other than storage, there's no facility for host configuration profiles or a way to apply a standard configuration to each host in a cluster.

RHEV management
Like the other platforms, RHEV runs with a data center and cluster mind-set, allowing you to collect hosts into various groups for ease of management and resource allocation. However, while storage is configured at the data center level and replicated across hosts, networks must be configured manually on every host in the cluster. The other solutions provide ways to replicate both storage and network configuration across hosts.

The desktop roots of RHEV surface in a number of places. Occasionally messages and alerts will specifically reference "desktops," while some features seem to have been built only with desktops in mind. For example, creating pools of VMs offers an easy and quick way to build plenty of servers from a single template, but limits the ability to configure them independently. You can't select a server built from a pool and turn high availability on or off, for instance, or set a priority level for that one server.

All the "big" features of server virtualization are present in RHEV, but some aspects don't function as you might expect. High availability and load balancing generally work quite well, but have a few quirks not seen in the other solutions. For example, if a single host has a very high VM load, and another server in the cluster is brought out of maintenance mode with no virtual machines whatsoever, virtual machines from the busy host will not begin migrating to the empty host unless at least one VM is manually migrated over. This manual step shouldn't be necessary.

Conversely, when a host is shut down via an external means -- such as by holding the power button or using remote management to power off the server -- RHEV will determine that the host has disappeared using IPMI hooks and begin booting the virtual machines that were flagged for high availability on other hosts. It will also automatically try to revive the downed host. However, if the host disappears completely and IPMI is no longer available -- as in the case of an abrupt power loss -- RHEV won't do anything unless and until an admin flags the server as down. This means that even virtual machines flagged for high availability will not automatically restart on other cluster hosts -- a big problem, should someone happen to unplug the wrong server or pull the wrong blade.

Part of the reason for the reliance on IPMI is the fact that RHEV doesn't use a clustering file system. Instead, it uses LVM (Logical Volume Management) on a single LUN to manage VM disks, which falls in line with the concept of KVM versus full hardware emulation. While the use of LVM provides some benefits, like the fact that LUN locking isn't required, it also has detriments -- such as the inability of a high-availability cluster to determine when a host has gone completely dark.

Overall, the RHEL Manager UI is attractive and capable. It does have some of the hallmarks of a Web application, such as configuration windows that cannot be resized, making it difficult to work when, for example, an IQN (iSCSI Qualified Name) is far larger than the window, requiring a bunch of horizontal scrolling and column resizing for proper identification.

RHEV's simple management interface collects all the management tools in a single place with a clean layout.
1 2 3 4 Page 2
Page 2 of 4