Day to day management of virtual machines yields some interesting lessons. Here are 10 recommendations for working with VMware vCenter 5.1.
Virtualization brings possibilities that were previously unheard of, or at least more difficult to achieve with physical systems. Most people don't equate IT with creativity (at least outside the field), but I have found that working with virtual systems has presented all sorts of creative scenarios. The ability to easily duplicate virtual machines; to take snapshots to save the current system status and "roll back" to this point in time later; to spin up and bring down test systems within minutes - all this has freed up IT staff for bigger and better things. Like many time-saving developments in technology I have found virtualization hasn't reduced headcount but actually increased it since it opens the door to more options.
I've worked with VMware environments for a few years now and currently spend a lot of hands-on time with 5.1. Here are some tips I've put together based on my day-to-day experiences, using the VMware vSphere client for Windows.
1. Be careful when cloning Windows systems on a domain
We have several virtual machine templates for Windows XP, 7 and 2008. At present, I leave them all off the domain, keeping them in the standard WORKGROUP instead. We join them to the domain after cloning them, because weird things can happen when you clone operating systems joined to an Active Directory domain. The clone or the original domain member might experience logon problems since now there is an imposter afoot. The issue is caused by the fact that each Windows computer has a unique ID - or to be precise, a SID (Security Identifier). This is like a fingerprint, and it is different for all Windows computers, or rather it should be for things to work properly. Mark Russinovich XP, Windows 7 and http://www.codeproject.com/Articles/45365/How-to-Sysprep-Windows-2008-Servers
Better yet, you can configure these alarms to provide you with direct notification when issues occur. Click on your main VCenter system, then choose the Alarms tab and click Definitions (to the right of View):
In this example, I want to set the Host CPU Usage alarm to define a warning if the percentage is at 75 or above for 5 minutes, and to send an alert if the percentage is at 90 or above for the same time.
In the above screenshot I set the email to go out if the condition changes from warning (yellow exclamation mark) to alert (red exclamation mark). You can set alerts if the condition changes from normal to warning, warning to alert, alert back down to warning, or warning back down to normal.
You can also add alarms to a virtual host by right-clicking it, choosing Alarm then Add Alarm (or clicking the VM and pressing Ctrl-M). You can then administer these individual alarms using the Alarm tab for that host.
I highly recommend you set disk storage alarms on your data stores (as well as other critical elements). Few things are scarier than running out of disk space in a virtual environment where multiple machines might go down in that scenario.
It's handy to view the sizes of your virtual machines to keep track of what storage space is being used or to see which virtual machines are on which data store. Press Ctrl-Shift-D to bring up the "Datastores and Datastore Clusters" view in the vSphere client:
I'll admit I was never a fan of the performance counters available in Windows systems. They seem too kludgy and cumbersome to set up. VMware offers some performance details under the Performance tab of each VM, which can give you a quick and easy glimpse as to how the virtual host is running:
Snapshots make virtualization fun, since you can restore a host to a prior state after you've completely mangled it (hopefully through experimentation only on a test host, but you get the picture). Snapshots aren't without a price tag, however – they take up disk space and slow down the cloning process, so they should be remove them, but make sure to test these first and don't run the latter unless you're positive the snapshots won't be needed.
10. Know your database
Your VMware ESX environment has a database, whether running on Oracle, a SQL instance or even IBM DB2. If that database has problems, so will your virtual machines. If you're lucky the VMs might still remain running in the event of a database failure, but I've seen scenarios where some virtual hosts went down hard – and they couldn't be brought back up right away since the database had problems.
Get to know how your database works, where it resides, how to support it, and all other relevant details in the event of a problem with it. Many system and network administrators have strong roots in one area and weaker experience in another. If databases aren't your thing, learn all you can about the one sitting underneath your VMware systems so that if (when) the day comes when you have to support it, you won't be stumbling blindly through Google searches. I've seen issues whereby a SQL Server Express database used for VMware reached the 4 Gb limit then shut down.