- VMware Technology Network
- :
- Help & Resources
- :
- LegacyUserBlogs
- :
- Legacy Blogs
- :
- VMware vSphere Support of Hyperscale and Embedded ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
VMware vSphere Support of Hyperscale and Embedded Servers, Part I
You may have noticed in the last few weeks that there are more Embedded servers being certified with VMware vSphere and showing up on the VMware hardware compatibility guide for servers. This is the result of a multiyear program by the VMware engineering team to more broadly enable processors, chipsets, and I/O devices within vSphere while still ensuring the robustness and reliability required by enterprise data centers and the cloud in general. This matters because it gives our customers more options in selecting the right server for their IT solutions. Or put another way, it allows our customers to worry even less about the platforms running their workloads in the cloud.
As an example of the expanding support by vSphere, consider the Cisco 5940 Series Embedded Services Router (ESR) [1] for which Cisco provides "the Unified Communications Manager (UCM) to support embedded deployments". "The Cisco 5940 ESR and a single board computer running UCM create Advanced Networking Nodes from which mobile ad hoc networks can be built for military, public safety, energy, industrial, transportation and smart grid applications." The UCM runs within vSphere and "Cisco has verified UCM running on both the Extreme Engineering Solutions XPedite7332 and the Emerson Network Power CPCI7203 single board computers."
I am happy to say that because of our expanded program (and a bit of extra help from our Hardware Enablement Quality Engineering team, "JB", and "PP"), both of these embedded platforms have been certified for VMware vSphere 5.0 Update 1 and are listed on our VMware Compatibility Guide. [2][3]
Why the need for an expanded program? You might think that extending enterprise x86 virtualization from server processors and chipsets to seemingly-related processors and chipsets in the mobile, desktop, and embedded segments is a simple task. We should be able to assume software compatibility within the same generation.
It turns out that even though processors and chipsets of the same generation are usually created equal (they often have the same RTL and possibly same chip die), they need not be manufactured, packaged, fused, and productized equally. This means that some members of a given generation may have more or less software-visible features than the average for that generation. For example:
- Some low-end desktop processors may be fused so that hardware virtualization support or advanced SIMD instructions are disabled.
- Some processors may have packages that do not expose the extra pins for ECC DRAM support.
- Some chipsets may have different PCI Device IDs for integrated I/O devices that could share the same vSphere I/O driver.
- Some platform BIOSes may disable hardware virtualization for a given processor, even though the processor micro-architecture is capable of it.
These differences within the same micro-architectural generation make it difficult for "blanket" assumptions about support and compatibility. On the other hand, if we make no assumptions, we end up with an impractical test matrix of every brand and model of seemingly related microprocessors and chipsets. To deal with this problem we developed the following internal process:
- We select and internally qualify the right mix of baseline representative processors and chipsets across all market segments (more than just servers).
- We work with our hardware partners to identify platforms which do not use a baseline processor or chipset.
- We then work with the microprocessor vendors to compare the micro-architecture and software-visible features of the non-baseline component with the baseline to ensure it supports required virtualization features and ECC for DRAM.
- Our simplifying assumption is that if this comparison checks out, we can allow a hardware partner to attempt certification of the platform w/o VMware first conducting a full qualification of the platform with its non-baseline component.
- If we have some doubt, then we do the needed extra qualification.
- Our assumption also rests on the fact that *all* platforms must pass VMware's rigorous server certification and all I/O device drivers must pass a similar set of tests.
Prior to this process, VMware enabled embedded technology platforms on a case by case basis, which was inefficient and narrowly focused. Now, VMware has laid the foundation for all of our partners to select the processors and chipsets they need and "self-enable" them through this process.
For the embedded platforms above, it was very easy to apply the process to permit vSphere certification. These platforms use an Intel Core i7-620LE, which is an Intel "Arrandale" core that shares the same micro-architecture as the Intel "Clarkdale" server processors already supported by vSphere. And both use a chipset similar to the "Ibex Peak" chipset that vSphere already supports. Lastly, unlike mobile processors, this embedded processor's integrated memory controller supports ECC for DRAM -- which is essential to mission critical workloads.
This is just one example of vSphere 5 expanding to cover a wide range of embedded processors, I/O devices and servers. Tomorrow, I'll discuss the next step to allow our customers even more choices for the hyperscale data center with vSphere.
References