Seven best practices for virtual machine management

Virtualization optimizes IT resource efficiency and saves costs spent on physical servers. However, the very benefits of virtual machines (VMs) can turn into scalability issues if VMs are left unmanaged. The purpose of this guide is to shed light on some simple, insightful, easy-to-implement VM management methods that can help you reduce the TCO and improve the ROI of your virtual infrastructure.

Segment VMs based on their roles

Just like with physical servers, it is important to group virtual servers based on what they do. This can solve several problems at once.

Set up dynamic resource allocation

Users demands vary. An ecommerce checkout service may see more action during the start of the month when paychecks arrive. Modern hypervisors adjust RAM at runtime without shutting down the VM. Technologies like Hyper-V Dynamic Memory or ballooning drivers in ESX/Xen reclaim unused memory from idle VMs and assign it to high-demand VMs.

It's recommended to enable dynamic resource allocation, to ensure that VMs hosting critical services can scale up to handle demand spikes.

Identify zombie VMs

Virtualization provides the capability to easily allocate storage space to VMs, but this can lead to both uncontrolled growth of virtual machines as well as over-allocation of resources.

Zombie VMs, also known as idle VMs, are VMs that were created and assigned resources for a specific purpose, and then forgotten about. These VMs are notoriously hard to find. While they don't generally use a lot of resources individually, if left unmanaged, they can proliferate and cause a noticeable resource drain.

Zombie VMs are a leading cause for VM Sprawl. VM sprawl can also open up security loopholes. The best way to fight zombie VMs is to create a checklist. The checklist should include the following tasks:

• Create a formal process for requesting and approving VMs.
• Monitor the life cycle of each VM.
• Monitor VM resource utilization to identify resource use by abandoned or idle VMs.

Virtualization monitoring tools like ManageEngine OpManager can help you perform the second and third steps of the checklist.

Enable failover clusters and migration

Hardware fails, and hosts need patching. Neither should mean downtime for the services running on top of them. Failover clustering groups multiple hosts so that if one goes down, the VMs it was running are automatically restarted on a surviving host in the cluster.

Migration handles the planned side of the same problem. Modern hypervisors can move a running VM from one host to another with no interruption to the user, using technologies like vMotion in VMware, Live Migration in Hyper-V, or XenMotion in Citrix.

There are two situations worth preparing for separately.

• Planned downtime: Before applying firmware updates or patching a host, migrate its VMs to another host in the cluster. The maintenance window becomes invisible to end users.
• Unplanned downtime: Configure high availability at the cluster level so that host failures trigger an automatic restart of the affected VMs elsewhere. Set restart priorities so that user-facing and business-critical VMs come back first.

A few things make the difference between a cluster that works and one that only looks like it does. Keep enough spare capacity in the cluster to absorb the load of at least one failed host, make sure shared storage is reachable by every host in the cluster, and test the failover periodically instead of assuming it will work when it matters.

Remove snapshots on a regular basis

Snapshots are one of the most useful features in virtualization, and one of the most frequently misused. A snapshot preserves the state of a VM at a point in time, which makes it ideal before an OS upgrade, a patch, or an application change that may need to be rolled back.

The problem begins when the snapshot is never deleted. Once a snapshot is taken, the original disk is frozen and every subsequent write goes into a delta file. The longer the snapshot lives, the larger that delta file grows, and the more work the hypervisor has to do to serve a single read. The results are predictable:

• Storage consumption: A forgotten snapshot can quietly grow until it fills the datastore, which can freeze every VM sharing that datastore, not just the one with the snapshot.
• Performance degradation: Long snapshot chains add latency to every disk operation. Several chained snapshots on an active database VM can slow it to a crawl.
• Longer consolidation times: The bigger the delta, the longer it takes to commit the snapshot back into the parent disk, and the greater the risk of the operation failing midway.

It’s also worth stating plainly: a snapshot is not a backup. It depends on the original disk being intact, so it offers no protection against storage corruption or loss.

The practical fix is a policy. Define a maximum snapshot age, cap the number of snapshots allowed per VM, and run a scheduled check that flags any snapshot older than the threshold so it can be consolidated or removed.

Perform VM monitoring and management

Every practice listed so far depends on visibility. You can’t segment what you haven’t inventoried, right-size what you haven’t measured, or find a zombie VM you don’t know exists.

Effective monitoring covers the entire stack, not just the guest OS. A VM can look healthy from the inside while the host underneath it is contending for CPU or the datastore it sits on is running out of space. At a minimum, keep an eye on:

• Host-level health: CPU and memory utilization, CPU ready time, memory ballooning and swapping, and datastore latency and free space.
• VM-level health: Resource utilization against allocation, guest OS availability, and disk and network throughput.
• Configuration changes: VM creation, deletion, resource reconfiguration, and snapshot activity, so that sprawl is caught early rather than discovered during an audit.

Thresholds matter as much as metrics. Alerts should be tuned so that they fire on sustained problems rather than momentary spikes, and routed to the team that can actually act on them. Too many false alarms and the real ones get ignored.

Virtualization monitoring tools like ManageEngine OpManager give you a single console across VMware, Hyper-V, Nutanix, Proxmox, and Xen environments, with automatic discovery of hosts and VMs, built-in thresholds, and reports that map VMs to the hosts and datastores they depend on.

Forecast resource capacity and usage

Monitoring tells you what your infrastructure is doing now. Capacity forecasting tells you when it will run out of room, which is the question your budget cycle actually depends on.

Forecasting works by applying trend analysis to historical utilization data. If CPU usage across a cluster has grown steadily for the last six months, that trend can be projected forward to estimate the point at which the cluster is exhausted. That estimate is what turns an emergency purchase into a planned one.

Capacity planning should answer two questions:

• When do we run out? Forecast performance trends for CPU, memory, and storage growth for each cluster and datastore. Identify the date each resource is exhausted at the current rate.
• What can we reclaim first? Use capacity planning reports to find over-allocated and idle VMs. Right-sizing oversized VMs and decommissioning zombie VMs often optimizes resource usage.

Revisit the forecast on a fixed schedule, because the assumptions behind it change. A single new business application or an acquisition can change a projection built on last quarter’s trend.

The right VM monitoring tool can help you enforce these best practices. Try ManageEngine OpManager for unified network, server, storage and VM monitoring.