« The Real Impact of vSphere | Main | Cisco and HP Square Off In Server Land »

April 21, 2009


Stephen Foskett


Great intro to MPIO! I'm really pleased to see more use of this tech across platforms!

Some questions:
1) Does PowerPath/VE require an Enterprise Plus license for vSphere 4? It looks like it does from the outside...
2) Does vSphere 4 include basic multipathing in the Standard edition?
3) What's the compelling value of moving up to PowerPath/VE from native MPIO?


Chuck Hollis

Hi Stephen!

1) I don't know -- Barry Burke is chasing that one down, I think -- on your behalf. It might, which would not be ideal.

2) I don't know. Chad would know the answer to that -- I'll reach out to him. (See, marketing guys can be really useful!)

3) In terms of value props, I'd offer (1) dramatically improved performance for I/O request-heavy workloads, (2) the option of using fewer channels/paths to achieve suitable performance, (3) less "burp" when paths fail, smoother recover when they're restored, and (4) probably a few other things that I've forgotten.

Simply put, PowerPath has become the defacto MPIO standard in demanding Windows/Linux/AIX/HP-UX/Solaris environments. If you're considering heavy workloads in vSphere, you should consider PowerPath for many of the same reasons people considered it for other OS environments.

-- Chuck


Certainly something I will look into once we decide to go to vSphere, assuming of course it will work on the version we end up with(likely essentials or standard)

Our I/O needs are not heavy(in VMs) I'm more interested in fast fail over.

thanks for the info!

John F.

Hi Chuck,

Powerpath/VE on the Windows platform leverages Microsoft MPIO. Nothing wrong with that. HP and NetApp and a cast of thousands do something similar. Aside from the garden variety MPIO DDK modules, there's the vendor specific logic in the custom Device Spoecific Module or DSM that differentiates one MS MPIO implementation from the next. I think digging in a little deeper into EMC's PowerPath/VE on WIndows DSM implementation could be enlightening, or at least educational. Do you have a technical paper or link to one with some meat on it that you could share?

Enquiring minds want to know.

Thanks in advance,


Chuck Hollis

Hi John

I'd have to flip you over to someone else to track this down. You're right, I do remember the "vendor specific logic" discussion from Windows MPIO -- I don't remember how it all ended up.

John F.

THat would be great if you could do that Chuck. The DSM is definitely where the rubber meets the road.


Stephen Foskett


Yes, PowerPath on Windows is a DDK for Microsoft's native MPIO. This is a Very Good Thing, and is exactly why Microsoft was brilliant to build an extensible path management platform into Windows!

And in fact VMware PSM is really very similar to MS MPIO, and is therefore also a Very Good Thing.

I don't want to have EMC ripping up the Windows or VMware I/O chain just to insert their path management logic. Why doesn't every OS offer something similar?

This is not to say that PowerPath's value is diminished. EMC basically does everything they should do (choosing paths, balancing IO) and nothing they shouldn't (mucking with the kernel).


Chuck Hollis

Thanks, Stephen -- I owe you one!!

-- Chuck

John F.

Hi Stephen,

You, Chuck (well for obvious reasons I can't speak for Chuck, but hopefully he'll roll with this one), and I all would clearly like to see similar functionality across the OS continuum. Standards like MS MPIO that leave room for OEMs to implement their specific value added features in a non-disruptive way are clearly a good thing. NetApp does their own ONTAP DSM, EMC has thier own DSM for PowerPath, Veritas their DSM, HP, and all the other vendors for that matter. That's how we differentiate ourselves from each other. I'm very interested to know what those features are for EMC that would differentiate them from say NetApp; that's all.



Chad Sakac

The vSphere PSA (Pluggable Storage Architecture) has three module types - SATP/PSP (which work with the native NMP module). An MPP (multipathing plugin) does the function of the NMP/SATP/PSP (which is roughly analagous to the DSM model of the Windows MPIO framework). Both the NMP and MPP use the MPIO framework using in vSphere.

The NMP/SATP/PSP model in vSphere is a big step up vs. VI3.5 for everyone - heck, basic round robin is now an option (not the default for any SATP - ergo any array, but can be manually configured)

VMware has made the API model open and available to all - but only EMC (so far) has done the work to build an MPP.

So - how this helps customers:

- Automated path discovery and setup – without needing rescans. For any large environment this is huge.
- Killing flaky paths proactively.
- Automated reconfiguration of paths.
- More comprehensive load-balancing (weighted, and variable depending on host conditions). This is particularly important for ALUA configurations (which most Mid-range arrays, including NetApp John F, use) - where the first "A" in ALUA stands for "asymmetric" - there is a distinctly GOOD and distinctly LESS GOOD path (due to transversing lower bandwidth internal busses). Simple round robin there can actually hurt - as the inequal path get used equally.
- Predictive load balancing (when used with EMC arrays) – this is HUGE.

Why? Remember – on an ESX cluster – when a path on one host gets busy – what’s the likely root cause? The array port being busy. Which ESX hosts in the cluster will this affect? ALL OF THEM.

First of all – round robin won’t do anything to use other paths more heavily, so will do nada (the busy paths get used the same as the less busy ones). PowerPath/VE (with any array) will do a better job of balancing. But PowerPath/VE with an EMC array will predictively move workloads based on the array ports starting to get busy.

long and short, NMP (Native Multipathing) helps when using Round Robin, but pales in comparison (both in terms of automation and really squeezing the most out of the connectivity).

The goal is to have PP/VE support be heterogenous (same as PP is today). The NetApp team has reached out to the EMC team to discuss this (in spite of all blog back n' forth - the customer comes first.

John F.

Thank you Chad for your informative post.

John F.

John F.

Looks like Stephen Foskett took the time to expound on the details as well http://blog.fosketts.net/2009/04/22/emc-powerpath-vmware-hyperv/

Thanks Stephen.



Some students pass the duty to professional writers because they miss the ability to compose a satisfactory paper about vSphere in that the reason why you need to use plagiarism detect, but such people like author don't do that. Thanks a lot for the topic

The comments to this entry are closed.

Chuck Hollis

  • Chuck Hollis
    SVP, Oracle Converged Infrastructure Systems

    Chuck now works for Oracle, and is now deeply embroiled in IT infrastructure.

    Previously, he was with VMware for 2 years, and EMC for 18 years before that, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Vero Beach, FL with his wife and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not ever buy him a drink when there is a piano nearby.

    Note: these are my personal views, and aren't reviewed or approved by my employer.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!