5 Things About Server Virtualization Managers Should Know (But Usually Don’t)

Unless you have been under a rock recently you have likely heard of and maybe even implemented some type of virtualization solution. If you have already been down this road already then this post might not help but for those manager types out there who might be considering a virtualization solution in the near future this post talks about some of the most common misconceptions regarding server virtualization and how you can avoid getting into trouble implementing your own virtualization solution.

Technorati Tags: linux, mac, management, data center, virtualization, vmware, Windows

Since virtualization was well on it’s way to being one of the major items on most IT manager’s (and engineer’s) radar this past year and this year looking to be more of the same I have been conducting my own research into what products and technologies do what and how can I make use of this in my own environments. After about 5 months casual testing, and lots of personal time using several virtualization products for personal use I have discovered some interesting factoids that might just save you some considerable time in your own virtualization research.

1. VMware is not the only vendor making quality virtualization products.
Vendors such as Oracle, Sun, VirtualBox, Parallels, Open Source (Xen) all have great solutions. If you have been either researching virtualization or have already integrated a virtualization solution into your 2008 IT planning you might think this is just common sense but I was surprised to discover how many folks were not aware that other vendors have been implementing both server and desktop virtualization solutions that perform just as well as VMware. I even had one self-proclaimed IT professional tell me that VMware “owns” the patent on virtualization….<not true>!

2. Server virtualization will not cure all your server consolidation & data center problems.
I know, silly to think that anyone who even knows the tiniest bit of facts about virtualization would think this way but you would be surprised. Lots of managers and top level executives simply just read the propaganda and think all will be cured by simply virtualizing everything in sight. The same kind of management trend was seen when “blade” servers were en vogue (you know who you are). Claims that blade servers would shrink and revolutionize the data center went (as expected) unfulfilled for the vast majority of IT shops who tried to migrate to them. Virtualization is similar in that you need to understand what it can and cannot do before you consider integrating it into your data center management strategy. Good example: Virtualizing your Windows Active Directory controllers that control your network access is not only wasteful but can actually be dangerous to your environment since it can remove the distributed and redundant nature of these systems (not to mention you might not get back into your systems if the host server goes down).

3. The performance of many applications will change when virtualized.
Don’t believe the hype, sometimes applications see a performance hit under virtualization. At the end of the day, you need to test (and test again) your applications in a good test environment before moving forward with any attempt to virtualize a platform or application. In my own testing I found that disk intensive applications and high memory usage applications tended to not perform anywhere near native performance while more mainstream applications such as Microsoft Sharepoint, Oracle (light to medium loads), mySQL, and many others performed close to or even slightly better under virtualization. One interesting side affect of virtualization is that most guest (the OS that has been “virtualized”) operating systems reboot in significantly less time, likely due to disk caching on the host OS.

4. Virtualization WILL significantly increase your storage requirements unless you tightly control things.
One of the really nice features of virtualization is the ability to rapidly create “test” or on-demand copies of a virtualized environments. The unfortunate side effect of this process is you can quickly end up with lots of copies eating up local disk space on the host machine. I recommend a two-fold approach in dealing with this; make users go through the same server request process for virtual machines that you would for physical hardware, and force users to store application data off local systems onto remote storage systems such as a SAN or NAS. One good technical strategy I found so far is to only allow your users (or whoever is generating the environments) to create virtual machines that have local disk images for the boot OS only. Have them map the data storage out to a SAN or NAS (or DAS for that matter) using ISCSI. VMware natively supports this and just about any product will allow for using this approach in the guest OS. What this does is eliminate the bad habit of storing application data locally inside each VM (virtual machine) wasting local storage and creating a backup nightmare.

5. Keeping usable backups of virtual machines is not as easy as you might think.
In order to implement a safe and dependable disaster recovery process for virtualized environments you should follow some basic advise. Never rely on just snapshots, while useful they are not always 100% reliable and are prone to human error while inconvenient full backups can take systems offline during the backup they will more often result in easier restores later. Like I stated in #4, good strategy is to keep your data on your SAN and the VMs on your host server and then develop a separate backup strategy for each.

Well that’s enough on server virtualization, check back soon for my next post which will deal with virtualization on the desktop.