In the not too distant future, however, the number of CPU sockets and the multiple CPU cores filling servers will lead to organizations cramming even more instances into them, thus elevating the need for still more instances to be moved quickly.And as servers become crammed with more instances, the need for load balancing CPUs and resources becomes more critical. The ability to move groups of VM assets from one server to another goes a long way towards maintaining peak performance from the multi-core servers now popular in network operations centers and data centers.
VSphere 4.1's core management application, vCenter, now runs only on 64-bit hosts. Upgrades to existing 32-bit platforms, like our Windows 2003 Server R2 host, aren't allowed, so some administrators will have to upgrade to 64-bit versions of their vCenter host.
Or you can just re-install, which is a more painful exercise. There are upgrade scripts to copy the database, but instructions aren't clear and we couldn't get it to work with our MS SQL Server 2005, as migration scripts failed. We gave up and created a new vCenter data center and imported the ESX machines (switching them to the new vCenter server).
The VMware ESX core hypervisor, has also been upgraded, and provided no upgrade drama at all; vCenter Update Manager upgraded our hypervisors to 4.1 level.
Memory management changes
VMware claims that memory use for VM instances is more efficient in 4.1 compared to 4.0. We tried to test overhead and found that 4.1 decreases memory overhead, but only for 64-bit instances. We couldn't find any real change for 32-bit virtual machine memory use over the same time cycles (many minutes).
Memory can also be compressed so that VMs don't go to disk for virtual memory as often, which saves access speed. We found that the amount of actual time savings from compression could be high, and is likely to be useful in constructions where VMs are crammed and somewhat over-subscribed, resource-wise.
CPU use changes
Unlike most other hypervisors, VMware 4.1's ESX uses processor sleep instructions to save power when idle. Most hypervisor kernels thwart processor sleep in a quest to be responsive to the random requests of hosted VMs, and keep CPUs at full speed all the time.
Sadly, there's not a hardware compatibility list (HCL) that notes which servers can use this feature, and while we were able to set power management policies on our Dell 1950 VMware ESX 4.1 host, we weren't able to deploy it on our HP servers. And on all three mainstream machines we tested, were unable to view power history, power consumption, or the power cap information. According to a VMware support person, "the graphs are supported on systems that have built-in power meters that we know how to read". We hope more can be read, soon.