VMware Vi3 - Virtual Center 2: Thoughts
This is a must read, the VI3 Resource Management Guide:
http://www.vmware.com/pdf/vi3_esx_resource_mgmt.pdf
For those about to take the journey of upgrading their ESX 2.5.x/VC 1.x environment to VI3/VC2, this is a great read that covers the logic behind DRS and HA. I must say that I think DRS can be useful when it comes to handling application SLA. Exempli gratia, you have a Weblogic farm of application servers that must have 80% of the server’s processor. Well, with DRS, you can do such a thing with only a few clicks.
While VMware pitches that the “Resource Pool” is an aggregate of ESX servers, it is in fact a collection with no aggregation of resources. Therefore, if I have four ESX Servers with 4 processors and 32GB of RAM, I can not physically allocated 8 processors and 80GB of RAM to a Virtual Machine. I am only using the pool to increase the probability that the resources will be available. I’m not thrilled about the concept, but I guess you have to start somewhere.
VCB, a new feature, seems pretty worthless to me as there is already a wildly popular Perl script to take hot backups of .vmdk’s. Not to mention, ESX Ranger is quite affordable and works brilliantly, if you are so inclined. With the overhead of taking .vmdk snapshots (as opposed to using a Backup Agent inside the VM) and the inability to extract specific files within the .vmdk backup, VCB has a long way to go as far as I’m concerned.
HA – High Availability. This was originally dubbed as “Clustering” in the pre-release documentation of VI3. They quickly realized that their solution does not meet the requirements for a proper definition of a cluster, so they changed it to High Availability. This moniker seems to fit, in my opinion. The premise is that .vmx files are now stored on shared storage on the new and improved VMFS-3 format (allowing a directory tree) so if an ESX server is struck by a Hezbollah rocket, then the Virtual Machines can be brought up on another ESX server. Kind of cool, but you are only picking one server to pair it to. Por ejemplo, you tell ServerA Virtual Machines to come up on ServerB should it die.
However, I have already implemented a solution that takes care of this. There is a cron’d hourly backup job that runs and copied the directory structure of /home/vmware (includes the vmx’s) to a sister ESX server at the secondary site. You can use the GUI (or I can code in some logic to detect a failure) that will rescan extract the contents of the .vmx backup, register the Virtual Machines on the sister ESX server and then power them up (and answer any questions along the way). I can do this for a group, farm or site of ESX servers. Perhaps I should sell this to VMWare.
Overall, VI3 is a great step in the right direction and they are still on the fore-front of Virtualization technology. I’m glad to see them start to think “pools of resources” and when they are able to somehow aggregate the resources, VI will be a true datacenter juggernaut.
- Jason Langone
Commenting is closed for this article.
2007 Systems Architech.