Rational Survivability

I've made no secret of my displeasure with the PCI Security Standards Council's lack of initiative when it comes to addressing the challenges and issues associated with virtualization and PCI compliance*. 

My last post on the topic  brought to light an even more extreme example of the evolution of virtualization's mainstream adoption and focused on the implications that cloud computing brings to bear when addressing the PCI DSS.

I was disheartened to find that upon inquiring as to status of the formation of and participation in a virtualization-specific special interest group (SIG,) the SSC's email response to me was as follows:

The follow-on email to that said there were no firm plans to form a virtualization SIG. <SIGh>

So assuming that was the carrot approach, I'm happy to see that VMware has taken the route that only money, influence and business necessity can bring: the virtualization vendor 'stick.'  To wit (and a head-nod to David Marshall🙂

Simon Crosby and I have been going 'round a bit lately arguing the premise of where, why, when, how and how much security should be invested by either embedding it in the virtualization platform itself or being addressed by third parties.

Simon's last sentence in his latest riposte titled "Hoff is Still Confused" was interesting:

Well, how the hell am I supposed to argue with that!? ;)  OK, now I am confused! Simon's taken the high road and thus I shall try to do so, too.  I wrote a ton more in response, but I'm not sure anybody cares. 😉

All told, I think we're both aiming at a similar goal in spite of our disparate approaches: achieving a more secure virtualized environment.

But seriously, I don't think that I'm confused about Citrix's position on this matter, I just fundamentally disagree with it.

I feel strongly that Simon and I really are on different sides of a religious issue but without a more reasonable platform for discussion, I'm not sure how we'll intelligently discuss this more coherently without all the back and forth.  Perhaps a cage match in sumo suits!?

I appreciate Simon clarifying his position and reaching out to ensure we are on the same page.  We're not, but the book's not closed yet. 

So we agree to disagree, and I respect Simon for his willingness to debate the issue.

/Hoff

Hat-tip to David Marshall for the pointer.

In what can only be described as the natural evolution of Xen's security architecture, news comes of a Xen community project to integrate a VM Introspection API and accompanying security functionality into Xen.  Information is quite sparse, but I hope to get more information from the project leader, Stephen Spector, shortly. (*Update: Comments from Stephen below)

This draws naturally obvious parallels to VMware's VMsafe/vNetwork API's which will yield significant differentiation and ease in integrating security capabilities with VMware infrastructure when solutions turn up starting in Q1'09.

From the Xen Introspection Project wiki:

The
purpose of the Xen Introspection Project is to design an API for
performing VM introspection and implement the necessary functionality
into Xen. It is anticipated that the project will include the following
activities (in loose order): (1) identification of specific
services/functions that introspection should support, (2) discussion of
how that functionality could be achieved under the Xen architecture,
(3) prioritization of functionality and activities, (4) API definition,
and (5) implementation.

It is important to note that this is not the first VMI project for Xen.  There is also the Georgia Tech XenAccess project lead by Bryan Payne which is a library which allows a privileged domain to gain access to the runtime state of another domain.  XenAccess focuses (initially) on memory introspection but is adaptable to disk I/O also:

I wonder if we'll see XenAccess fold into the VMI Xen project?

Astute readers will also remember my post titled "The Ghost of Future's Past: VirtSec Innovation Circa 2002" in which I reviewed work done by Mendel Rosenblum and Tal Garfinkel (both of VMware fame) on the LiveWire project which outlined VMI for isolation and intrusion detection:

What's old is new again.

Given my position advocating VMI and the need for inclusion of this capacity in all virtualization platforms versus that of Simon Crosby, Citrix's (XenSource) CTO in our debate on the matter, I'll be interested to see how this project develops and if Citrix contributes. 

Microsoft desperately needs a similar capability in Hyper-V if they are to be successful in ensuring security beyond VMM integrity in their platform and if I were a betting man, despite their proclivity for open-closedness, I'd say we'll see something to this effect soon.

I look forward to more information and charting the successful evolution of both the Xen Introspection Project and XenAccess.

/Hoff

Update: I reached out to Stephen Spector and he was kind enough to respond to a couple of points raised in this blog (paraphrased from a larger email):

Bryan Payne from Georgia tech will be participating in the project and there is some other work going on at the University of Alaska at Fairbanks. The leader for the project is Stephen Brueckner from NYC-AT.

As for participation, Citrix has people already committed and I have 14 people who have asked to take part.

Sounds like the project is off to a good start! 

I was reading an interesting article from James Maguire from Datamation that outlined various competitors in the virtualization platform space.

In the article, James referenced a Gartner slide that comparatively summarized hypervisor selection criteria including the maturity of features, pricing, management and ultimately security.  Unfortunately the presentation source of the slide was not cited, but check this out:


What I found very interesting was the security section which equated the security capability/maturity criteria of Oracle with that of VMware while at the same time demonstrating that the overall maturity/stability of Oracle was not has highly ranked. 

Since Oracle's hypervisor is based upon Xen and Citrix/XenSource is not ranked as high, it leaves me scratching my head.

Given that this chart references hypervisor selection to YE08, it more than likely does not take into consideration the coming vNetwork/VMsafe API's; it's unclear if this section is a measure of VMM "security" based upon published vulnerabilities, an assessment of overall architecture, the availability of security solutions in the ecosystem…

This is a very interesting assertion and I'd really like to get the entire document that describes how this was quantified and what it means.  Anyone know which report this came from?

/Hoff

One of the things I'm very much looking forward to with the release of Cisco Nexus 1000v virtual switch for ESX is the release of performance figures for the solution.

In my Four Horsemen presentation I highlight with interest the fact that in the physical world today we rely on dedicated, highly-optimized multi-core COTS or ASIC/FPGA-powered appliances to deliver consistent security performance in the multi-Gb/s range. 

These appliances generally deliver a single function (such as firewall, IPS, etc.) at line rate and are relatively easy to benchmark in terms of discrete performance or even when in-line with one another.

When you take the approach of virtualizing and consolidating complex networking and security functions such as virtual switches and virtual (security) appliances on the same host competing for the same compute, memory and scheduling resources as the virtual machines you're trying to protect, it becomes much more difficult to forecast and preduct performance…assuming you can actually get the traffic directed through these virtual bumps in the proper (stateful) order.

Recapping Horsemen #2 (Pestilence,) VMware's recently published performance results (grain of NaCl taken) for ESX 3.5 between two linux virtual machines homed to the same virtual switch/VLAN/portgroup in a host shows throughput peaks of up to 2.5 Gb/s.  Certainly the performance at small packet rates are significantly less but let's pick the 64KB-64KB sampled result shown below for a use case:

Given the performance we see above (internal-to-internal) it will be interesting to see how the retooling/extension of the networking functions to accomodate 3rd party vSwitches, DVS, API's, etc. will affect performance and what overhead these functions impose on the overall system.  Specifically, it will be very interesting to see how VMware's vSwitch performance compares to Cisco's Nexus 1000v vSwitch in terms of "apples to apples" performance such as the test above.*

It will be even more interesting to see what happens when vNetwork API's (VMsafe) API calls are made in conjunction with vSwitch interaction, especially since the performance processing will include the tax of any third party fast path drivers and accompanying filters.  I wonder if specific benchmarking test standards will be designed for such comparison?

Remember, both VMware's and Cisco's switching "modules" are software — even if they're running in the vKernel, so capacity, scale and performance are a function of arbitrated access to hardware via the hypervisor and any hardware-assist present in the underlying CPU.

What about it, Omar?  You have any preliminary figures (comparable to those above) that you can share with us on the 1000v that give us a hint as to performance?

/Hoff

* Further, if we measure performance that benchmarks traffic including
physical NICs, it will be interesting to see what happens when we load
a machine up with multiple 10Gb/s Ethernet NICs at production loads
trafficked by the vSwitches.

From Virtualization.com comes the news that VMware has acquired BlueLane Technologies

BlueLane is the maker of solutions that protect both physical and logical infrastructure which includes ServerShield and VirtualShield.  The company has of late focused wisely on
the latter which provides application-aware firewalling, inter-VM flow visibility and analytics, application policy control, and intrusion prevention capabilities.

Coupled with the introspection capabilities provided by VMware's vNetwork/VMsafe API's natively, the integration of BlueLane's solution sets will add to the basal capabilities of the platform itself and will allow customers the flexibility to construct more secure virtualized operating environments.

The notion of enabling in-line patch-proxying as well as the "IPS-like" in-line vulnerability mitigation capabilities for VM's and additional VMM protection make this very interesting indeed.  You can read more about BlueLane's approach on their website.  I also interviewed Allwyn Sequeira on my blog.

VMware's acquisition of Blue Lane comes as no surprise as it became clear to me that in order to continue to strengthen the underlying platform of the hypervisor itself, I wrote earlier this month prior to rumors of Blue Lane's acquisition by other bloggers that as part of a successful differentiation strategy:

Of course, I actually talked about it a year ago when Determina was acquired…

I think it's actually an excellent move as it continues on the path of not only helping to ensure that the underlying virtualization platform is more secure, but the elements that ride atop on it are equally "security enabled" also. 

This point was at the heart of my debate with Simon Crosby, Citrix Systems' CTO (see here and here);
focusing solely on VMM resilience and leaving the ISVs to sort out security was a bad idea.  It  leads to more siloes, less integration, more complexity and overall a less secure environment.

We need a unified secure ecosystem to start with instead of worrying about securing the ecosystem's products.

Form a business perspective it takes a mixture of resolve, market dominance, and confidence to cannibalize a section of your ecosystem, but it's the right thing to do in this case in order to offset competitive forces and help customers solve some really nasty issues.

I made mention of this point with emerging security ISV's at Vmworld, and was asked several times whether I really thought VMware would do this.  The odd question that inevitably came next was "were does that leave security ISV's like us?"  You can guess my answer.  Honestly, I'm sure most of them were hoping to be bought for the same reason.

So, will this cause a run on alignment to support Hyper-V over VMware?  I don't think so.  ISV's who were hinging their hopes for success solely on VMware understand this risk.  Microsoft has no API facility like vNetwork/VMsafe, so the options for reasonable and rational installation of their products are limited.  Citrix is in the same boat.

This is the reason my next set of VirtSec presentations will focus on Hyper-V.

On a side note, I was one of Blue Lane's first customers for their patch proxy product and have been an ardent supporter of their approach for many years, despite taking quite a bit of crap for it from purists and pundits who had difficulty rectifying the approach in comparison to traditional IPS'.

This is a good thing for VMware, VMware's customers and Blue Lane. Congratulations to the BlueLane team.

I spend a good amount of time thinking about how multiple technology strategies from market leaders coalesce into a reasonably homogenized version of reality in the networking and security space in order to decide where to place bets; it's akin to reading a tell and analyzing a player's betting strategy at a poker table.

I look at Cisco and VMware and can't help to chuckle at the moves being made in the name of "partnership" on the virtualization front and there's an awful lot of twitching going on that doesn't require Phil Hellmuth to decode. 

Partnerships are nothing new, but usually they are couched with certain modicum of suspicion and cynicism.  However, speaking with folks at VMworld, either folks were high from the Oxygen Bar at the airport, or they were adding naiveté syrup to the drinks because I seemed alone in my concerns…

I've put together a couple of summary points on the matter — more for my own personal enjoyment and note taking than anything else — and framed them in terms of what I find to be really annoyingly obvious examples of these two strange bedfellows' behaviors:

1)  The purported cohesion of Cisco's and VMware's virtualization strategies is a simply a matter of converged parallelism and forced perspective.

You've seen diagrams that demonstrate the notion of converged parallel lines, right?  If you haven't here's an example:

You'll notice that in this diagram there exists a series of parallel lines which seem to converge at a "vanishing point" on the horizon.

This in fact is not the case.  The lines don't actually ever converge, they just look like they do.  It's all a matter of perspective.  Imagine these lines as Cisco's and VMware's virtualization strategies.

Similarly, the notion of forced perspective is a method by which the manipulation of perspective employs an optical illusion to make something appear closer, father away, larger or smaller than it actually is (see the title image above*.)

The announcements from Cisco and VMware are very much like these examples. Whilst they offer excellent opportunities for improving the management and security of virtual infrastructure, it's very much Machiavellian marketing — the end is going to justify the means.

Speaking to either Cisco or VMware you're asked to suspend disbelief and accept that these two companies share a common blueprint for a datacenter OS, but they don't.  In fact, they're quite different, and the balance of who needs whom more is also very lopsided.

Despite the close technical partnership needed to pull off the integration of the Nexus 1000v as the first third party virtual switch (which we've been talking about for almost two years,) Cisco and VMware really are on parallel trajectories in terms of their visions regarding the datacenter OS; how it's designed, provisioned, deployed, managed and governed…and by whom.

Cisco is approaching this primarily as an infrastructure transformation play as a way of clawing back what they lost when the network access layer become absorbed into the virtual hosts while VMware is busy distancing itself from the infrastructure and elevating the discussion to that of the cloud in an effort to stave off Microsoft and Citrix.

Each want to own your datacenter, and while they play nice on the surface, there's really a nasty game of tug of war going on here.  This is a marriage borne of convenience, nothing more.

You try and unify Cisco's DC 3.0 vision with VMware's Virtual Datacenter OS blueprint and tell me how they mesh.

2)  Dear Virtual SysAdmin: You're fired as the network admin.  You're cool with that, right?

It's funny how both Cisco and VMware's marketing folk in the sessions discussing the release of the Nexus 1000v vSwitch, both snarkily (and rhetorically) posited "How many of you Virtual SysAdmins have coordination and communication issues between your virtualization and network teams?"

Leading the witness further, the next question was  "Don't you just hate having to fight to get the network teams to give you a trunk port on an access switch?" 

They followed that up with "Your prayers are answered!  The 1000v will allow you to give the network provisioning back to the network  teams and let them control the networking and connectivity.  Isn't that great?" 

While most nodded away in the affirmative to the first and second questions, I didn't see one audience member who answered positively on the latter.  What makes anyone think the vSysAdmins *want* to give up the control of the virtual networking layer and be at the mercy of the networking teams again?

Interesting battle ground for sure.  Now, please don't misinterpret my commentary as a suggestion that this is a bad thing, but we're already in the middle of a "West Side Story" turf war over organizational fiefdoms.  This will, depending upon what sort of contention exists already, make a really tenuous issue even more so.

3) Software Sucks.  Hardware Rules.   I hope you like ping pong.

I hinted at this point in my post titled (The Network is the Computer…)  The reality is that much like point #1, Cisco could care less in the long term about the Nexus 1000v as a software switch running in someone else's backyard operating environment, but rather introduces it to enable the landscape clawback it gets to enjoy in the short term and make relevant once again it's big network iron in the longer timeframe.

A telling slide was the announcement of what's coming AFTER the Nexus 1000v in one of the sessions that I have not seen presented in detail elsewhere — that is Cisco's goal to extract networking out of the host completely.

The plan as discussed is to utilize what Cisco calls an "initiator" to replace the 1000v and force traffic, after specialized tagging which denotes affinity of flows to specific VM ID's, and ship them straight back out the network interfaces to a waiting Cisco 5000/7000 switch for processing.  Hence the ping-pong mention above.

Sorry for the quality of the picture as I took it sitting behind somebody, but here's a slide denoting just this very thing:

 
The notion of a third party switching capability is really just a way for Cisco to push the access layer back to where they think it rightfully belongs — in the physical switch.

Cisco claims that VMware and they have submitted this tagging specification to the IEEE for review/ratification.   I find that very interesting.

I wrote about the need for such a technology at both the virtualization layer and more importantly the application/data level in June of 2007. 

Check out my post which described how I suggested Crossbeam do the exact same thing by way of something I called ADAPT (Applied Data and Application Policy Tagging) which describes this very thing.  What's next, they're going to announce vNAC? 😉

—

All in all, the Cisco/VMware relationship is about as natural looking as the Microsoft/Citrix version — it's sort of like a midget dating a six foot supermodel…someone's getting the better end of the footrub in that relationship, too.

So, how about it?  Am I stating the obvious again — and does it need to be stated?

/Hoff

*image from "The Eye of Brad" flickrstream

Rich Miller from one of my favorite blogs, Telematique, wrapped up his VMworld 2008 coverage in a post titled "What Happens In Vegas…"

Rich made a number of very interesting observations, one of which caught my eye:

I'd agree with Rich to a point, except for the part about how "no one made too much of security issues…"
There was at least one schmuck waving his arms and I'm wearing his underwear 😉

As I alluded to in my post titled "VMWorld 2008: Forecast For VMware?  Cloudy…Weep For Security?" the messaging associated with this years re-branding certainly had the word "security" front and center under the Application vServices pillar:

…but as Rich alluded to and my post made mention, the bulk of VMware's security efforts would appear to focus primarily on what's coming from VMsafe and the ecosystem partners supporting it:

I think, however, this would be a rather short-sighted perspective.

While the tremendous amount of re-branding and messaging certainly "clouded" the horizon in some cases, it was clear that the underlying technology roadmap that was shown (and demonstrated as being real in the labs I participated in) lays down some pretty significant clues as to what's in store from VMware in regards to security.  More on that in a minute…

You might recall my debate with Citrix's CTO, Simon Crosby, on what, where and how virtualization platform providers should invest in terms of security.  Our divergent views were quite passionate, but I maintain that my perspective is that echoed by the majority of the folks I've spoken to over the last 3 years.

My position, presented in this post, is best summarized thusly:

It's important to understand that I'm not suggesting that virtualization platform providers should secure the actual guest operating systems
but they should enable an easier and more effective way of doing so when virtualized.

I mean that the virtualization platform providers should
ensure the security of the instantiation of those
guests as "hosted" by the virtualization platform.  In some cases this
means leveraging technology present in the virtualization platform to
do things that non-virtualized instances cannot. That's more than just
securing the hypervisor."

What did I mean by that?

Obviously since I was using VMware as the model for my position, I was referring to VMsafe as the ecosystem enabler, but I was also referring to VMware's prior security acquisition in 2007 of Determina as a fundamental building block for the virtualization platform's security efforts.

Pair that with the root of VM/VMM introspection that Mendel and Tal Garfinkel envisioned back in the day, and things start to make sense…

So back to the original point of this post, which is where VMware's efforts are focused in terms of security.  I think that this year's show concreted a two definites in my book:

1. VMware will make additional acquitisions in the security space.  Yes, I know this sounds heretical given the delicate balance most "platform" providers keep with their ecosystem partners, but VMware have already shown that they are ready to buy as well as build and ally with prior acquisitions and security will continue to be a key differentiator for them.  They've done it once already with Determina, they'll do it again.
    
2. The level of commitment and investment shown by both Cisco and VMware shows there will be a continuing deeply-concreted technology integration between the two beyond the Nexus 1000v.  The software instantiation of the Nexus functionality is a fantastic story when combined with the larger vNetwork/distributed virtual switch approach, but I maintain it's a stop-gap. 

   The real picture (for Cisco) is clearly a thinner software layer within ESX and a further dependence upon switching hardware external to the host (the Nexus 5000/7000) with of course more security capabilities being provided by the external iron.  Why?  Read my Four Horsemen presentation: virtual switching and virtual security appliances — both in software — ultimately don't scale, don't perform and don't play well with the rest of the stack.

   What does that have to do with VMware's strategy?  Well, to me it's an indication that while virtual appliances are great for many things, security isn't necessarily one of them and that the platform has to be bolstered with as much security huevos as makes sense, allowing the commodity functionality to be shipped off to ISV's software.  I mean, that's why the stuff demo'd by the ISV's looks just like existing solutions — with VirtualCenter integration.  A firewall's still a firewall, AV's still AV…the model changes a bit, so back we go to the network.

   Remember this post?: Security Will Not End Up In the Network… It sounds a little contradictory to the point I just made, but read the post.  For the sake of this one, it simply illustrates that cyclically, we're swinging the pendulum back to the "network."  However, where the "network" is becomes a little nebulous.

   More on this concept in a separate post soon.

What this ultimately means to me is that within the next 24 months with the delivery of VI4, a mature VMsafe API and shipping ISV code, we'll see some of the natural market consolidation activity occur and VMware will lock and load, snap up one or more of the emerging security players in the VirtSec space and bolster their platform's security capabilities.

Meanwhile Cisco will help secure VMware further in the enterprise with their integrated play and the remaining security ecosystem players will begrudgingly fight to stay on the good side of the fence…while they hedge their bets by supporting Microsoft and Hyper-V.

I think we've just seen the beginning of what VMware has to offer from a security perspective.  They (and us) have a tremendously long way to go, but every cloud's got a silver lining…

/Hoff

If there's one motif emerging from VMworld this year, it's very much the maxim "be careful what you ask for, because you might just get it."

The precipitate convergence of virtualized compute, network and storage is really beginning to take significant form; after five hard years of hungering for the materialization of the technology, enterprise architecture, and market/business readiness, the notion of a virtualized datacenter OS with a value proposition larger than just " cost-optimized infrastructure" has now become a deliciously palpable reality.  

The overlap and collision of many leading technology providers' "next generation" datacenter (OS) blueprints is something I have written about before.  In many cases there's reasonable alignment between the overall messaging and promised end result, but the proof is in the implementation pudding. I'm not going to rehash this here because I instead want to pick on something I've been talking about for quite some time.

From a network and security perspective, things are about to (again) fundamentally and profoundly change in terms of how we operationally design, provision, orchestrate, manage, govern and secure our infrastructure, applications and information.  It's important to realize that this goes way beyond just  adding a 'v' to the name of a product. 

What's incredibly interesting is the definition and context of where and what makes up the "network" that transports all our bits and how the resources and transports interact to deliver them securely.

It should be clear that even in a homogenous platform deployment, there exists an overwhelming complex conglomerate of mechanisms that make up the machinery enabling virtualization today.  I think it's fair to say that we're having a difficult time dealing with the non-virtualized model we have today.   Virtualization?  She's a cruel mistress bent on reminding us we've yet to take out the trash as promised.

I'm going to use this post to highlight just how "complexly simple" virtual networking and security have become using as an example the last two days' worth of  announcements, initiatives and demonstrations of technology and solutions from Intel, VMware, Cisco and the dozens of security ISV's we know and love.

Each of the bumps in these virtual wires deserves its own post, which they are going to get, especially VMware's vNetwork/VMsafe, distributed network switch, and Cisco's Nexus 1000v virtual switch announcements.  I'm going to break each of these elemental functions down in much more detail later as they are simply amazing.

Now that networking is abstracted across almost every layer of this model and in many cases managed by separate organizational siloes and technologies, how on earth are we going to instantiate a security policy that is consistent across all strata?  We're used to this problem today in physical appliances, but the isolation and well-definable goesinta/goesouta perimeterized boundaries allows us to easily draw lines around where these

policy differentials intersect. 

 It's used to be the devil you knew.  Now it's eleven different devils in disguise.

As you visualize the model below and examine how it applies to your experience, I challenge you to tell me where the "network" lives in this stack and how,  at a minimum, you think you're going to secure it.   This is where all those vendor roadmaps that are colliding and intersecting start to look like a hodgepodge:

In the example model I show here, any one of these elements — potentially present in a single VMware ESX host — can directly or indirectly instantiate a set of networking or security functions and policies that are discrete from one another's purview but ultimately interrelated or even dependent in ways and using  methods we've not enjoyed before.  

In many cases, these layered components are abstracted from one another and managed by separate groups.  We're seeing the re-emergence of  network-centricity, it's just that the  network is camouflaged in all its cloudy goodness.  This isn't a story where we talk about clearly demarcated hosts  that plug into "THE" network, regardless of whether there's a hypervisor in the picture.

Here's where it gets fun…

In this model you have agents in the Guest OS interacting with security/networking virtual appliances on the ESX host either inline or via vnetworking APIs (switching or security) which in turn uses a fastpath networking kernel driver  connected to VMware's vSwitch while another VA/VM is connected to a Cisco Nexus 1000v vSwitch implemented as a second distributed virtual network switching fabric which are all running atop an Intel CPU utilizing SR-IOV via VT-d in the chipset which in turn allows VM's to direct attach (bypassing the VMM) to NIC cards with embedded switching connected to your network/storage fabrics…

Mass hysteria, cats and dogs living together…

So I'll ask you again: "Where's the network in that picture?"  Or, more precisely, "where isn't it?"  

This so hugely profound, but that may because I've been exposed to each of the bubbles in this diagram and see how each of them relate or do not.  When you step back and look at how, as an example, Cisco and VMware are both going through strategic sea changes in how they are thinking about networking and security, it's truly 

amazing but I think the notion of network intelligence is a little less cut and dry as some might have us believe.

Is this as mind-blowing to you as it is to me?  If not, wait until I rip open the whole vNetworking and Nexus 1000v stuff.  Very, very cool.

/Hoff

This post was written prior to the opening of the Partner Day/Technology Exchange, based solely upon information that is publicly available.  No NDA's were harmed during the making of this blog…

So now that I can talk about it outside of the embargo, VMware is announcing extensions to its product roadmap and product marketing to deliver what it calls its "virtual datacenter OS:"