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!
Comments Locked


View All Comments

  • venice1 - Thursday, February 26, 2009 - link

    Well written and informative, Liz. What is your assessment of the overall attitude, energy and expectations of this years attendees? Has VMware risen to a level that validates this event every year? Have you been able to attend any of the workshops? What are your thoughts on holding VMworld Europe two years in a row at Cannes and is the city an ideal location for fostering growth and partnerships within the virtualization world? Anxiously waiting for your next article.
  • LizVD - Friday, February 27, 2009 - link

    Thanks for the compliment, and I'm currently working on it. The big problem with being a journalist at these conferences is that they don't really expect the press to attend the breakout sessions, and as such stuff our schedule with a lot of less interesting stuff. ;-)

    Now that we're back home, more updates are forthcoming however, expect another post later today!
  • duploxxx - Friday, February 27, 2009 - link

    have been to the event for several years now, even before it was called "world" but rather just "TX".

    It is clear that from that point on the focus was changed, before it was all about the technical part, real vm freaks, now you also see a growing focus on the marketing aspects and to my opinion the original true technical is fading a bit, the breakout sessions are decent but there are very few real advanced sessions but 90% will do for the daily overall user and that is what you see more and more in the vmworld, customers that have a system deployed attending these sessions, they don't need more technical then this.

    Location is fine, nice weather, nice location and don't forget its about 4500 people, not so easy to find the right locations.
  • has407 - Wednesday, February 25, 2009 - link

    The only time things need to synch is when the VM produces a side effect that is externally visible; i.e., I/O. All such activity is visible to the hypervisor. The only information that needs to be sent is the VM state information that has changed since the last update, which the hypervisor should be able to figure out with relatively little effort.

    I expect the algorithm is more like "since the last I/O or after X seconds". In any case, the amount of data that needs to be sent is considerably less than maintaining a "clock per clock" copy, and yields exactly the same results--except that some CPU cycles might be duplicated when the shadow copy starts, but if there's been no I/O during that period, then no harm and no foul.

    Obviously other optimizations are possible depending on the type of IO, as certain types of I/O might not require an update. For example, reading from a disk wouldn't necessarily require an update.
  • haplo602 - Wednesday, February 25, 2009 - link

    Well if you think about it, there is only one way how the fault tolerance feature can work - progressive VMotion.

    It starts a VMotion and when it is complete, it is simply syncing the VMs page table data while the VM is not running on a CPU (or it interrupts it for this) between the original VM and the shadow copy.

    Something like that was done very long ago with L4 microkernel running a Linux instance inside. However the data was much smaller at that time.
  • duploxxx - Wednesday, February 25, 2009 - link

    it's actually the record and replay functionality that is already available in workstation 6, but this time enhanced and off course to be FT it needs the "ok" from the other part, interesting things they implemented to reduce the overhead with reads and writes and proven to be very powerfull, now we only need this on more vcpu. A nice addon is the self-healing :) one goes down a new one comes up.
  • LizVD - Thursday, February 26, 2009 - link

    Indeed, later that day we had the chance to interview Lionel Cavalliere of VMware EMEA and grill him a bit about the subject. It seems at this point, Fault Tolerance will indeed be limited to single vCPU VM's and will give quite a bit of overhead. Not quite ready to use for company-critical database systems and such, I guess.

    I like the idea, though, using a combination of existing techniques to provide a completely new way of handling High Availability. Definitely goes to show how much the IT landscape has changed since virtualization came along.

Log in

Don't have an account? Sign up now