10 things to NOT do with your VMs

This is the 156th article in the Spotlight on IT series. If you’d be interested in writing an article on the subject of backup, security, storage, virtualization, mobile, networking, wireless, DNS, or MSPs for the series PM Eric to get started.

I’ve virtualized, what could go wrong? As most of us know, there’s plenty that can go wrong. In my professional experience, the one thing that is consistent is that I never stop learning — be it formal training, a mentoring program or learning by trial and error (something I’ve seen my fair share of). Based off these “learning experiences” of my own and those I’ve observed from others, here are 1- 10 things to NOT do with your virtual machines (VMs).

1. Not having a backup. This may seem quite elementary, but the fact is with VMs we still need a backup. I’ve seen a number of situations where enabling technologies such as virtualization has made a business move faster from a procedural standpoint, but the procedures around data protection don’t always keep up — and eventually this becomes a problem. When it comes to backing up VMs, I recommend people take the time to build a solution that will grow with them, specifically incorporating organic growth of VMs over time. The best way to do this is to put to use the vSphere or Hyper-V constructs already in place. This can include resource pools, clusters, folders, datastores or entire hosts. That way, backups function on a container level, leaving no VM without a backup.
2. Loving abstraction, not having separation. This one I’ve been guilty of in the past. When it comes to tasks such as VM backups, it doesn’t make much sense to have the VM and its backup residing on the same datastore. While we have virtualized, we don’t have to stray from our standard practices of ensuring there are proper domains of failure in between our source VMs and their backup resources.
3. Going too big. While I love the ability of VMware virtual machines to scale quite large (monster VMs, anyone?), there are still a few things to watch out for. One that I see occasionally is taking a snapshot of a virtual machine with a VMDK set to 2 TB. VMDKs that need to be snapshotted need to be a size of 2 TB – 512 bytes. (Check out this VMware KB for more info.) What have I done after learning this? I set my templates to be 2 TB – 512 bytes and use thin provisioning.
4. Skipping drivers. One of the best ways to mess up a VM is to omit the driver enlightenment kit. For VMware virtual machines, this is VMware Tools and for Hyper-V this is the Integration Services kit. These drivers are critical for the fastest performance of the VMs while also ensuring that the drivers inside the guest are correct so there are no unknown devices. It’s also important to note that keeping these drivers up to date is important. One important new feature of vSphere 5.1 includes the new VMware Tools drivers allowing seamless updates! That’s a great segue to no. 5 of my list…
5. Running VMs on an obsolete host. This is an easy one to overlook. While we may be happy with virtualization platforms and our needs may not change much, we may also be missing out. One example is the new VHDX format in Windows Server 2012 with Hyper-V. The new VHDX disk format allows virtual disk files to be up to 64 TB. On the vSphere side, newer versions of vSphere allow the Monster VM to be run. You can currently run a VM up to 64 virtual CPUs and 1 TB of RAM! That’s an incredibly large VM! If you’ve held on to older vSphere editions, you also may be missing out on the newest clustered file system, VMFS. VMFS-5 has made incredible improvements in scale and usability, and for some that is reason enough to upgrade.
6. Not taking the right shared storage approach. Shared storage is a great technology, and virtualization does great with it. But, make sure you’re not missing out on the performance and capability of your storage. This can include having monitoring to the storage to ensure the performance is optimal and possibly identifying VMs that are unfair consumers (space and I/O) of the precious resource. Same goes for local storage: Are you using it? Should you be? Give some thought to storage; chances are you can find something that isn’t correct in the current configuration.
7. Missing alerts. If your virtualization infrastructure has an alarm, alert or problem, you need to know about it. Take the time to ensure both VM elements and virtual infrastructure components are providing the right notifications to the right place. Is it a pager (they’re still out there, folks), text message, phone call, email or help desk ticket? What’s the right way to handle alerts in your environment? Make sure it’s set up right.
8. Allowing unnecessary spikes. A good example here is anti-virus software. Having every VM do a scheduled full scan at the same time is not a good idea. Trust me.
9. Not having adequate out-of-band support. Virtualization is great, until there is a problem. If you don’t have your day-to-day administrative console, ensure you have the right additional management tools. This can include a low-level management controller such as an HP iLO or Dell DRAC and can be supplemented by administrative tools such as SSH on an ESXi host or Remote Desktop enabled on the Hyper-V host. Site KVMs also are a good tool to have in the arsenal.
10. Over-permissioning virtualization. I’m guilty here again. If you have a lot of stakeholders in your virtual infrastructure, it’s very possible that you may provide them access. In fact, it’s a great way to give console access and virtual power buttons to application owners, if your environment supports that type of access. But be sure you don’t inadvertently provide too much access to application owners, or even IT staff. The fact is that VMs can be deleted very easily, and once this is done, you’ll understand how important no. 1 on this list is. I like to use the roles and folders approach in VMware vSphere. It will allow you to have separated levels of access yet provide stakeholders the right amount of self-service.

Have you learned anything NOT to do with your VMs? Share your tips below in the comments!

Edited Feb 7, 2013 at 2:13 PM