March 2012

You are currently browsing the monthly archive for March 2012.

The question of VMware’s future in the face of increasing competition is not a new one; it’s been batted around by quite a few folks. So Steven J. Vaughan-Nichols’ article “Does VMware Have a Real Future?” doesn’t really open any new doors or expose any new secrets that haven’t already been discussed elsewhere. What it does do, in my opinion, is show that the broader market hasn’t yet fully digested VMware’s long-term strategy.

Before I continue, though, I must provide disclosure: what I’m writing is my interpretation of VMware’s strategy. Paul M. hasn’t come down and given me the low-down on their plans, so I can only speculate based on my understanding of their products and their sales strategy.

Mr. Vaughan-Nichols’ article focuses on what has been, to date, VMware’s most successful technology and product: the hypervisor. Based on what I know and what I’ve seen in my own experience, VMware created the virtualization market with their products and cemented their leadership in that market with VMware Infrastructure 3 and, later, vSphere 4 and vSphere 5. Their hypervisor is powerful, robust, scalable, and feature-rich. Yet, the hypervisor is only one part of VMware’s overall strategy.

If you go back and look at the presentations that VMware has given at VMworld over the last few years, you’ll see VMware focusing on what many of us refer to as the “three layer cake”:

  1. Infrastructure
  2. Applications (or platforms)
  3. End-user computing

If you like to think in terms of *aaS, you might think of the first one as Infrastructure as a Service (IaaS) and the second one as Platform as a Service (PaaS) or Software as a Service (SaaS). Sorry, I don’t have a *aaS acronym for the third one.

I believe that VMware knows that relying on the hypervisor as its sole differentiating factor will come to end. We can debate how quickly that will happen or which competitors will be most effective in making that happen, but those issues are beside the point. This is not to say that VMware is ceding the infrastructure/IaaS market, but instead recognizing that it cannot be all that VMware is. VMware must be more.

What is that “more”? I’m glad you asked.

Let’s look back at the forces that drove VMware’s hypervisor into power. We had servers with more capacity than the operating system (OS)/application stack could effectively leverage, leaving us with lots of servers that were lightly utilized. We had software stacks that drove us to a “one OS/one application” model, again leading to lots of servers that were lightly utilized. Along comes VMware with ESX (and later ESXi) and the ability to fix that problem, and—this is a key point—fix it without sacrificing compatibility. That is, you could continue to deploy your OS instances and your application stacks in much the same way. No application rewrite needed. That was incredibly powerful, and the market responded accordingly.

This compatibility-centered approach is both powerful yet limiting. Yes, you can maintain status quo, but the problem is that you’re maintaining status quo. Things aren’t really changing. You’re still bound by the same limitations as before. You can’t really take advantage the new functionality the hypervisor has introduced.

Hence, applications need to be rewritten. If you want to really take advantage of virtualization, you need a—gasp!—platform designed to exploit virtualization and the hypervisor. This explains VMware’s drive into the application development space with vFabric (Spring, GemFire, SQLFire, RabbitMQ). These tools give them the platform upon which a new generation of applications can be built. (And I haven’t even yet touched on CloudFoundry.) This new generation of applications will assume the presence of a hypervisor, and be able to exploit the functionality provided by it. However, a new generation applications that are still bound by the old ways of accessing those applications will constrain their effectiveness.

Hence, end users need new ways to access these applications, and organizations need new ways to deliver applications to end users. This explains VMware’s third layer in the “three layer cake”: end-user computing. Reshaping applications to embrace new form factors (tablets, smartphones) means re-architecting your applications. If you’re going to re-architect your applications, you might as well build them using a using a new platform and set of tools that lets you exploit the ever-ubiquitous presence of a hypervisor. Starting to see the picture now?

If you look at VMware only from the perspective of the hypervisor, then the question of VMware’s future viability is suspect. I’ll grant that. Take a broader look, though—look at VMware’s total vision and I think you’ll see a different picture. That’s why—assuming VMware can execute on this vision—I think that the answer to Mr. Vaughan-Nichols’ question, “Does VMware have a real future?”, is yes. VMware might not continue to reign as an undisputed market leader, but I do think their long-term viability isn’t in question (again, assuming they can execute on their vision.)

Feel free to share your thoughts in the comments. Do you think VMware has a future? What should they do (or not do) to ensure future success? Or is their fall a foregone conclusion? I’d love to hear your thoughts. I only ask for disclosure of vendor affiliations, where applicable. (For example, although I work for EMC and EMC has a financial relationship with VMware, I speak only for myself.)

Tags: , , , ,

I just finished reading a post on ZDNet titled “Are Hyper-V and App-V the new Windows Servers?” in which the author—Ken Hess—postulates that the rise of virtualization will shape the future of the Microsoft Windows OS such that, in his words:

The Server OS itself is an application. It’s little more than (or hopefully a little less than) Server Core.

The author also advises his readers that they “have to learn a new vocabulary” and that they’ll “deploy services and applications as workloads.”

Does any of this sound familiar to you?

It should. Almost 6 years ago, I was carrying on a blog conversation (with a web site that is now defunct) about the future of the OS. I speculated at that point that the general-purpose OS as we then knew it would be gone within 5 to 10 years. It looks like that prediction might be reasonably accurate. (Sadly, I was horribly wrong about Mac OS X, but everyone’s allowed to be wrong now and then aren’t they?)

It should further sound familiar because almost 5 years ago, Srinivas Krishnamurti of VMware wrote an article describing a new (at the time) concept. This new concept was the idea of a carefully trimmed operating system (OS) instance that served as an application container:

By ripping out the operating system interfaces, functions, and libraries and automatically turning off the unnecessary services that your application does not require, and by tailoring it to the needs of the application, you are now down to a lithe, high performing, secure operating system – Just Enough of the Operating System, that is, or JeOS.

The idea of the server OS as an application container—what Ken suggests in very Microsoft-centric terms in his article—is not a new idea, but it is good to see those outside of the VMware space opening their eyes to the possibilities that a full-blown general purpose OS might not be the best answer anymore. Whether it is Microsoft’s technology or VMware’s technology that drives this innovation is a topic for another post, but it is pretty clear to me that this innovation is already occurring and will continue to occur.

The OS is dead, long live the OS!

<aside>If this is the case—and I believe that it is—what does this portend for massive OS upgrades such as Windows 8 (and Server 2012)?</aside>

Tags: , , , , ,

Yesterday I posted an article regarding SR-IOV support in the next release of Hyper-V, and I commented in that article that I hoped VMware added SR-IOV support to vSphere. A couple of readers commented about why I felt SR-IOV support was important, what the use cases might be, and what the potential impacts could be to the vSphere networking environment. Those are all excellent questions, and I wanted to take the time to discuss them in a bit more detail than simply a response to a blog comment.

First, it’s important to point out—and this was stated in John Howard’s original series of posts to which I linked; in particular, this post—that SR-IOV is a PCI standard; therefore, it could potentially be used with any PCI device that supports SR-IOV. While we often discuss this in the networking context, it’s equally applicable in other contexts, including the HBA/CNA space. Maybe it’s just because in my job at EMC I see some interesting things that might never see the light of day (sorry, can’t say any more!), but I could definitely see the use for the ability to have multiple virtual HBAs/CNAs in an ESXi host. Think about the ability to pass an HBA/CNA VF (virtual function) up to a guest operating system on a host, and what sorts of potential advantages that might give you:

  • The ability to zone on a per-VM basis
  • Per-VM (more accurate, per-initiator) visibility into storage traffic and storage trends

Of course, this sort of model is not without drawbacks: in its current incarnation, assigning PCI devices to VMs breaks vMotion. But is that limitation a byproduct of the current way it’s being done, and would SR-IOV help alleviate that potential concern or issue? It sounds like Microsoft has found a way to leverage SR-IOV for NIC assignment without sacrificing live migration support (see John’s latest SR-IOV post). I suspect that bringing SR-IOV awareness into the hypervisor—and potentially into the guest OS via each vendor’s paravirtualized device drivers, aka VMware Tools in a vSphere context—might go a long way to helping address the live migration concerns with direct device assignment. Of course, I’m not a developer or a programmer, so feel free to (courteously!) correct me in the comments.

Are there use cases beyond providing virtual HBAs/CNAs? Here are a couple questions to get you thinking:

  • Could you potentially leverage a single PCI fax board among multiple VMs (clearly you’d have to manage fax board capacity) to virtualize your fax servers?
  • Would the presentation of virtual GPUs to a guest OS eliminate the need for a paravirtualized video driver, and would the lack of a paravirtualized video driver streamline the virtualization layer even more? The same goes for virtual NICs.

I’m not saying that all these things are possible—again, I’m not a developer so I could be way off base—but it seems to me that SR-IOV at least enables us to consider these sorts of options.

Regarding networking, this is where I see a lot of potential for SR-IOV. While VMware’s networking code is highly optimized, the movement of Ethernet switching into hardware on a NIC that supports SR-IOV has got to free up some CPU cycles and virtualization overhead. It also seems to me that putting that Ethernet switching on an SR-IOV NIC and then adding 802.1Qbg (EVB/VEPA) support would be a sweet combination. Mix in a hypervisor-to-NIC control plane for dynamically provisioning SR-IOV VFs and you’ve got a solution where provisioning a VM on a host dynamically creates an SR-IOV VF, attaches it to the VM, and uses EVB to provision a new VLAN on-demand onto that NIC. Is that a “pie in the sky” dream scenario? I’m not so sure that it’s that far off.

What do you think? Please share your thoughts in the comments below. Where applicable, please provide disclosure. For example, I work for EMC, but I speak for myself.

Tags: , , , , ,

While browsing my list of RSS feeds tonight, I came across a series of articles by John Howard, a senior program manager on the Hyper-V team at Microsoft. The post was one of a series of posts describing SR-IOV support in the next version of Hyper-V, found in Windows “8″. I hadn’t heard that Microsoft was adding SR-IOV support to the next version of Hyper-V, so when I saw that I was surprised. Personally, I think SR-IOV support is a big deal (see the note at the end of this post for why).

If you’re not familiar with SR-IOV, I suggest you read this quick SR-IOV tutorial I published on this site in late 2009.

Here are the links to John’s SR-IOV in Hyper-V posts:

Everything you wanted to know about SR-IOV in Hyper-V, part 1
Everything you wanted to know about SR-IOV in Hyper-V, part 2
Everything you wanted to know about SR-IOV in Hyper-V, part 3
Everything you wanted to know about SR-IOV in Hyper-V, part 4
Everything you wanted to know about SR-IOV in Hyper-V, part 5

It’s great to see Microsoft adding SR-IOV support to Hyper-V; this brings SR-IOV out of the niche Linux market and into a broader, more mainstream market. This also applies some competitive pressure against market leader VMware, who now has to respond in some fashion—either by adding SR-IOV support to their ESXi hypervisor, or by explaining why SR-IOV support isn’t necessary. Personally, I hope that VMware does the former and not the latter.

(By the way, for those of you wondering why SR-IOV is important, there are lots of potential synergies here—in my view, at least—between hardware switching on an SR-IOV NIC and things like software-defined networking.)

Tags: , , , ,

Last year I had the opportunity to attend Cisco Live in Las Vegas for the very first time, and it was a tremendously rewarding conference. I guess I did enough liveblogging and tweeting at the show that I garnered the attention of the Cisco Live social media team, who just shared with me a scoop regarding the guest speakers at this year’s Cisco Live in San Diego.

Here’s the scoop: this year’s guest speakers are none other than Jamie Hyneman and Adam Savage of the wildly popular “Mythbusters” TV series!

As I’m sure many of you are, my family and I are big fans of the series and watch it quite frequently. I’ve never seen Jamie and Adam speak publicly before so I don’t know how entertaining it will be, but if it’s as good as the show it should be a great talk!

Hopefully I’ll have the opportunity to attend Cisco Live again this year so that I can see this!

I’ll update this post with a link to the official announcement as soon as the announcement goes live.

UPDATE: The official Cisco Live announcement page is now up and available here.

Tags:

I just finished reading the Internet Draft for Stateless Transport Tunneling (STT), a proposed protocol for network virtualization. STT’s contemporaries are VXLAN (Virtual eXtensible Local Area Network) and NVGRE (Network Virtualization using Generic Routing Encapsulation), both of which are also described in IETF Internet Drafts. The goal of all of these protocols is to virtualize (abstract) the physical network topology and bring functionality like isolation of multiple tenants, isolation of overlapping address space between multiple tenants, expanded VLAN/tenant ID address space, and enhanced VM mobility (by providing L2 services over an L3 network, for example).

I’ve written a little bit about VXLAN before; see my post titled Examining VXLAN for more details.

After reading the STT draft, I’m struck by a few initial thoughts:

  • The STT draft proposes the use of “TCP-like” headers to take advantage of hardware-based TCP Segmentation Offload (TSO) support. The headers look enough like TCP to allow existing TSO support in network interface cards (NICs) and other devices to work, but are different enough that a STT-unaware receiver would simply drop the packets. STT even uses the same IP protocol number (6) as TCP.
  • Although the STT headers “look” like TCP, there is no TCP handshake or connection state maintained. The draft authors acknowledge that this is both good and bad; it’s good in that the overhead of managing TCP connections is avoided, but bad that intermediary devices (like firewalls) that might ordinarily leverage TCP state information will no longer be able to do so with STT flows.
  • Like VXLAN and NVGRE, STT can be negatively impacted by “middle boxes,” devices in the physical network between the STT endpoints that might potentially interfere with the traffic. Firewalls are one key example; without STT support in the firewalls, it’s an either/or solution: either all STT traffic passes (based on the STT “TCP-like” destination port) or no STT passes. As I said, though, this is not unique to STT; VXLAN and NVGRE also suffer from the same issue.
  • The STT protocol draft makes special accommodations to enable more efficient processing of STT frames, such as providing an “L4 offset” that allows an STT-aware device to immediately know where the start of the inner TCP/UDP payload starts (instead of having to perform extensive parsing of the headers).
  • To provide an expanded address space, STT leverages a 64-bit “Context ID,” which could be used in any number of ways: expanded VLAN IDs, customer/tenant IDs, etc. VXLAN, on the other hand, supplies a 24-bit ID that is explicitly called out as the VXLAN Network Identifier (VNI). Similarly, NVGRE uses a 24-bit Tenant Network Identifier (TNI). STT’s Context ID is both larger and more generic.
  • Like VXLAN and NVGRE, physical networking equipment will not be aware of STT.

A few questions also arise:

  • Is the performance benefit realized by—as the draft authors state—having STT “explicitly designed to leverage the TSO capabilities of currently available NICs” really that significant? The STT draft states that the protocol was designed this way to improve the performance of data transfers, implying that STT’s architecture and use of TSO enables it to provide better performance than VXLAN (which encapsulates inside UDP) or NVGRE (which encapsulates inside GRE).
  • What are the drawbacks of re-using the TCP protocol number and repurposing TCP header structures for different purposes? Does this set a precedent that could potentially have negative repercussions? Does this open the door for vendors to “co-opt” standard protocol numbers and header structures for their own purposes, and what effect will that have on the network industry?

The one key takeaway that I have from reading the draft is just how much the “network virtualization” space is like a Wild West shoot-out: it’s a big free-for-all with competing (proposed) standards and competing (proposed) protocols like VXLAN, NVGRE, and STT; each of these proposals offers some unique strengths but also has some drawbacks and limitations. Maybe I’m just naive, but it seems to me the sort of broad interoperability to which we’ve become accustomed in IP-based networks is in danger of being fragmented along vendor lines: VMware-based networks deploying VXLAN, Microsoft-based networks deploying NVGRE, and Nicira throwing STT in there for good measure (presumably with STT support in Open vSwitch). It will be interesting—perhaps even challenging—as these various proposals sort themselves out. That is, of course, assuming that they sort themselves out.

Courteous comments are always welcome; please feel free to speak up in the comments! Also, please disclose affiliations where appropriate; for example, although I work for EMC, these thoughts are mine and mine alone.

Tags: , ,

On February 13, just before the official start of VMware Partner Exchange in Las Vegas, NV, I had the opportunity to present at the EMC Boot Camp. It’s beginning to seem that all my presentations focus on stretched clusters, but I assure you that’s not the case (give me a day or two and I’ll prove it to you). In any case, here’s the deck that I used during my presentation at the EMC Boot Camp.

Part 1 of this presentation closely mirrors the presentation that I gave in Australia (see here); Part 2, however, is new material that was presented for the first time at the EMC Boot Camp. This part contains some current recommended practices in the event you decide that a stretched cluster is the right solution for your organization.

Questions, suggestions, clarifications, or corrections are always welcome. Jump right in via the comments below!

Tags: , , ,

In early December of last year, I had the great opportunity to travel to Australia to participate in the inaugural full-day VMUG conferences in both Brisbane and Melbourne. I have been remiss in publishing the presentation that I gave at those meetings, so I’m fixing that now!

As always, if you have any questions, clarifications, or thoughts, please feel free to speak up in the comments. Thanks!

Tags: , , ,