
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
Figure B
http://www.codeproject.com/Articles/45365/How-to-Sysprep-Windows-2008-Servers

You can open each alarm to view details and set the desired configuration:
Figure C

Click the Triggers tab to set the conditions you want to put in place:
Figure D

Figure E

Finally, I can specify the appropriate action to take – in this case to send a notification email:
Figure F

7. Get an in-depth view of your VM hosts
Figure G

Figure H

8. Take advantage of built-in performance counters
Figure I

Figure J

9. Use snapshots… but remove them later
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.