Here we are once more, blogging away after a very interesting second keynote by VMware CTO Stephen Herrod, delving a bit deeper into the actual changes being pushed into different levels of the software. At this point, the amount of information available might actually fill up an entire article, but alas, time constraints force me to keep this short.

First and foremost, Herrod talked about the performance leaps that have been made over the past year, stressing the importance of moving every aspect of the data center into the cloud, to fully utilize its possibilities. He quoted performance studies using both a heavy OLTP database (using Oracle) and SPEC's very own SPECweb2005 bench to prove that performance hits are quickly becoming a non-issue (weren't they saying this last year as well, though?). Oracle was claimed to run at 24000 transactions per second, while the webserver was able to maintain up to 3 billion pageviews a day. Not too shabby compared to Ebay's average of 1 billion pageviews. The image below displays Oracle's virtual performance when using 1, 2, 4 and 8 vCPU's. The green bar is its native performance on an 8-core machine, VMware claims the performance loss is now limited to 15%.

The most interesting part of the keynote, however, was getting a more technical explanation of exactly what will change in VMware's current offerings to promote their vision of Cloud Computing.

As stated in yesterday's blog, VMware's input on the virtualized data center is threefold: the vSphere forming the management foundation for the internal cloud, the vCloud allowing for federation and interoperability between clouds both internal and external, and the vClient making all of these technologies available to actual end-users through various means.

vSphere is essentially the successor to the current Virtual Infrastructure suite, encompassing all of VMware's software that is actually installed on a physical server meant for virtualization (ESX, VMware HA, VMotion, etc.). The suite has been improved on many levels, some of which we'll be describing here. The big word to keep in mind through all of this is "automation". A lot of this stuff is technically already possible, but requires a very heavy monitoring set and team of very script-savvy administrators.

First of all, the release of VMotion introduced a few logistical problems on the networking level. While every piece of information inside the VM could be transferred to a completely different hardware system without a glitch, each ESX maintains its own virtual switch, which can be specifically configured for a VM running on it. When moving to a new physical server, this information was lost in the past, prompting VMware to develop the vNetwork Distributed Switch. This technology will allow the vSphere to maintain a centralized management of the virtual network, providing the administrator the ability to manage the virtual network of his cloud just as easily as a physical one, while allowing VMotion to happen without the loss of network states. Herrod mentioned switch vendors like Cisco are already working on plugins for the vNDS, helping out network admins to manage their virtual switch with the same tools they're used to for physical switches.

Another great aspect of the vSphere will be Distributed Power Management. The vSphere will be able to monitor the load put on its cloud and scale its physical buildup accordingly. The picture below demonstrates this effect quite nicely. While a regular data center will definitely see its power consumption change according to the load dropped on it, there's nothing quite as power saving as simply VMotioning little used VM's and powering off a machine. Automating this process will be a big hit for companies trying to reduce their carbon footprint. Note: I edited the picture a bit to make the graph more clear, since our seating during the keynote left a lot to be desired.

Updates of existing features of Virtual Infrastructure include the long-expected High Availability improvements. VMware HA was until this point mostly limited to VMotion for planned downtimes, and plain reboots of the VM at a different location for unplanned downtimes. This system left applications that couldn't handle a plain reboot out in the cold, so developers were still forced to implement failover systems. All of that is about to change with VMware's new Fault Tolerance feature, however, vSphere's new feature related to HA. Essentially, Fault Tolerance builds a shadow copy for VM's that require the highest possible availability. The shadow copy is a shielded off machine that is completely unaccessible for as long as the original VM is still running, but is synchronized "clock per clock" (or so we've been told) with it. Ideally, from the moment the original VM goes down, the shadow copy is pushed forward and is able to continue the work from the very CPU instruction the original dropped the ball on.

Exactly how this is achieved over a standard network connection is something that remains a bit of a mystery to us, more on that later, hopefully.

On the security level, VMSafe is built into the hypervisor to function as a sort of virtual firewall, allowing third party developers to plug into its functionality and release a virtual appliance that handles security for VM's whichever way they prefer, acting as an external antivirus that is uncorruptable from within the VM itself.

While all of this greatly improves standalone systems just as well, as virtualization continues its steady grow, many administrators find themselves required to manage not just one, but large amounts of physical servers, hosting thousands of virtual machines. To their aid, VMware has another product called vCenter, which essentially plugs into all available machines, and allows for central management of multiple virtual hosts. This product has been improved on several levels as well: implementing high availability by using vCenter in failover, using heartbeats to make sure everything is performing as it should.

While vCenter is limited in its management capabilities (up to 200 physical hosts, running up to 2000 virtual machines), it will be possible to link up to 10 vCenters to one another, allowing for central management of up to 20000 virtual machines in total. VMware saw it fit to implement a nifty little search function into their client, to keep things more manageable.

Thirdly, vCenter will allow the use of vCenter Host Profiles, enabling administrators to build a set of basic configuration rules for every host to be check against. This way, it's possible to push mass configuration changes to several physical hosts at once, forcing them into compliance of the news rules with just a right-click > Apply.

In any case, that's as far as time permits me to write this morning. Time to follow some more sessions and somehow cram more hours into a day to finish the rest. See you at the next blog!