StoreVirtual Storage
Showing results for 
Search instead for 
Did you mean: 

P4300 with VMware MPIO not using second card

Occasional Visitor

P4300 with VMware MPIO not using second card



Running a P4300 v9.5.00.1215.0 and cannot for the life of me get Vmware to use both NICs.



Configured to use MPIO - 2 iSCSI cards with separate addresses & following HP's vsphere best practices document.


We also have an equallogic that seems to work great.  Here's what I'm doing for that:

Virtual IP (physicals .11 & .12).  In VMware -> Storage Adapters I add a Dynamic Discovery target of the VIP (.10) in the ISCSI software adapter.  It detects two paths, .11 and .12 and i configure for Round Robin and everything works great.


On Lefthand, not so much.


No Bond

Virtual IP (physicals .8 & .9)

Every time I point VMware's software ISCSI adapter to the virtual IP (.7) it connects both (.23 &.33) to .9 and never connects to .8.  Confirmed with performance monitor and switch, no activity on 1 card.



Virtual IP (bond .9)

I point Vmware's software ISCSI adapter to the virtual IP (.7) and it connects 2x (.23 & .33) to .9.  However it still only uses 1 NIC.  Confirmed with performance monitor and switch.


LACP/802.3ad (Force10 configured for LACP)

Virtual IP (bond .9)

I point Vmware's software ISCSI adapter to the virtual IP (.7) and it connects to .9 but only on 1 adapter (.23).  The other one fails (.33)


I'm out of ideas.  For all the documentation that HP puts out for Vmware integration they seem to spend little to no time explaining best practices for setting up the LeftHand.  At this point i think if i could get "no bond" to be seen by VMware as .8 and .9 instead of both seeing .9 MPIO would do the rest, but it doesn't want to do that for some reason.



Valued Contributor

Re: P4300 with VMware MPIO not using second card

In order to see multiple connections from one initiator, you have to be using HP DSM, which is not available for VMware.

Your best bet is to create an ALB bond on each of the LH nodes, and couple that with  LACP and Round Robin on the VMware side.

With mutiple inititators, you'll see connections to both nodes in the cluster, even though you're pointing to the same VIP.


These limitations  have been covered extensively  on this board.



Occasional Visitor

Re: P4300 with VMware MPIO not using second card

First off thanks for the links!


I'm sorry, perhaps I didn't explain myself correctly.


I am not clustering LH nodes.  I am simply trying to get a single LH node with 2 onboard NICs to use both NICs.


On the LeftHand node I've tried no bonding, ALB, and LACP but neither seems to allow the system to use both NICs. 


I'm attaching a pic of what I'm seeing.  This is with the Node using ALB and VMware pointing at the Virtual IP (which then gets redirected to the bond).



What I'm trying to achieve looks very similar to this:

As you can see at the bottom of the document there are multiple iSCSI sessions from a single initiator visible on both the LH node and the VMware box.


At this point I seem to be able to prove from my own tests that MPIO is working correctly on VMware and can connect to LH the way it wants to, what I can't seem to prove is that the LH is capable of running active/active on two NICs in any of the available configurations.



Honored Contributor

Re: P4300 with VMware MPIO not using second card

Have you read up on LCAP/ALB so you really understand them?  if you are tyring to get close to full utilization of both NICs on the node you need to use LCAP and not ALB, but unless you have a stacked switch configuration it means your switch will be a SPOF and that is typically not desirable.  


Assuming you have an ok managed switch, have you checked on the switch to make sure the trunk configured to connect to the two ports of the storage node are actually bonding with the switch?  My guess would be that this is a switch configuration issue and the 2nd NIC is going into passive mode because the switch isn't letting it join the bond correctly since using ALB/LCAP, you only get one logical IP/MAC address which rules out MPIO as the issue.