Eight Tips for Virtualization

TipsIf you haven’t yet started installing WAN optimizers and the like as virtual appliances rather than as discrete hardware, you probably will soon. Indeed, it may well run parallel with the general push towards virtualization that most organizations are seeing. With that in mind, here are few tips to help make your virtualization project a success.

1. Plan the hardware. Just because the working servers are virtual, that doesn’t mean you can stop paying attention to the hardware — they still have to run on something. And that something is increasingly host hardware specifically designed as a virtual machine (VM) host, with multiple high-powered Ethernet and Fiber Channel ports, oodles of memory, and other performance-boosting add-ons designed to ease the load of supporting multiple hungry VMs on a single box.

Remember, too, that compared to a single server setup, a collection of VMs can behave in odd and unpredictable ways. For example, because the host’s scheduler lacks visibility into the individual VMs, the I/O stream will probably look quite random and impossible to optimize — the so-called I/O Blender effect. Adding more spindles or SSD is one option, others are storage hypervisors and virtualization. Either way, there’s a lot to plan, learn, and tweak when building a VM host.

2. Virtual monitoring and capacity planning. Virtual machines (VMs) aren’t fire-and-forget. They need monitoring just as much as physical ones do, though of course this can and should be automated where possible. Tools such as Solarwinds, Splunk, Veeam, and the native ones offered by VMware can all help here.

VMs also need lifecycle management. They may not have any hardware of their own to go end-of-life or need upgrades, but they need snapshots and backups, and they will grow and acquire the usual software upgrade cruft over time. Keep track of it.

3. Create and use VM templates. Many of the servers you create will be more or less standard, so create a template that you can use to do the grunt-work of configuring a new VM. Even better, create a set of templates for the various standard base servers that you use.

This also makes it easier to create temporary or disposable systems — for example, extra web servers to handle periodic capacity bumps, or when you need a file/ print server for a short-term project. These VMs can then be dissolved once they are done with — but remember no.2 above, and monitor them so you know what is and isn’t still in use.

4. Use those guest add-ons and tools. Host systems such as Hyper-V, VMware, and Xen also come with tools for guest operating systems, to do things such as seamless mouse capture, clock sync, sound and video integration, and so on. Don’t ignore them or assume they are just “chrome” — installing them will normally make your VMs a lot easier to use and manage.

5. Thick disks or thin? Yes, much of the time you will want to use thin provisioning — by creating a large logical volume but only allocating physical disk space when there is real data to fill it, it can produce significant improvements in storage utilization. But where performance is important, using traditional fully-allocated thick volumes will take out a layer of overhead. Of course, it will also affect your storage metrics and planning: you will probably need to have more physical disk available, or reduce the number of VMs per host.

6. Hunt down those single points of failure. If your virtual environment depends on a system, such as a domain controller, it is probably best to keep that physical, or at least to ensure it is physically replicated for redundancy. Similarly, anything your physical environment depends on, such as security systems, should not be virtualized if you need that physical access to manage the virtualization. It sounds silly, but it is easily done.

As ever, the key is planning: map out your virtual environment and all the interrelationships, and look at what happens when elements fail or become physically and virtually inaccessible. Just as with your physical systems, put backup systems in place.

7. Patch and secure the host. This is another single point of failure, but an easily missed one: yes, it is the guests VMs that do the work, but they all rely on the host and its operating system. You have probably already thought of what might happen if the host failed, and planned to backup and migrate its VMs, but what about data security? If an intruder — human or malware — or an unauthorized staffer got access to the host, what sort of damage could they do, or what could they extract or steal? Make sure your host servers are patched and secured, and if a certain system really needs to be secure, consider keeping it physical, if only to remove a potential avenue of attack.

8. If it ain’t broken… If you are virtualizing existing systems, think hard about which ones to take on. Virtual systems are not free by any stretch of the imagination, and not every system or application can use the benefits that virtualization can bring, such as seamless migration, faster provisioning and hardware abstraction. Conversely, high performance systems — ones that requires masses of RAM, CPU or disk I/O — may not work as well in a virtual environment. Beware, too, of converting physical systems to virtual — for some it will work well, but an ancient Windows 2000 server with a decade of accumulated software updates and other junk? It might be time for a rebuild. Lastly, if it’s mission-critical, test, test, test, and test again before putting the virtualized version live. Oh, and keep the original machine in place, ready to power up again, until you’re sure the new VM works as required.