• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

MD3000i Dualplex Controllers - Partial/No Redundancy

R

RiDDLeRThC

2[H]4U
2FA
Joined
Jun 13, 2002
Messages
3,963
So i finally converted my MD3000i from Simplex to Duplex by adding a secondary controller. Now my entire iscsi network is fully redundant. (two switches, two controllers, two nics in each server).

Now my question is, why does ESX not think they are?

partial-no-redundancy.JPG
 
all 4 paths on each server are up. I can see them, I can xfer load to them. That document was followed to a T. The paths are up. Had some issues bringing the second controller online but with the help of dell support and a dell engineer we were able to.
 
In storage management what does your settings on the Failover Path tab look like?

If you run
vmkmultipath -q
Click to expand...
what do you get?
 
Last edited:
Well only one controller can seem to own the LUN at one time (this normal across all iscsi sans?) I only have experience with the MD3000i.

Managed paths looks good, i even disabled two of the active/active i/o connections and it rolled over to the standby without problem. My array then threw up a message saying that the LUN wasn't using the preferred path. I went ahead and set it in the storage mgmr as the preferred path and then re-enabled the disabled paths and it stuck on the ones it last used.

The screenshot above hasn't changed tho.
 
Yea it can only be owned by one at a time.

HA does not mean Load Balance
 
So why does ESX seem to think its not redundant? wonder if its a bug or something.
 
Is it because I only have 1 iSCSI software adapter? (cant have more than one can I?)

maybe it only figures it as fully redundant if you have iscsi hba's?
 
hmm yea you would think that woulda been fixed.

Can you add a second software iscsi initiator?
 
Yes i have 4 targets listed, two ports on each controller, 2 controllers.

I'm presenting 4 LUN's to my ESX Servers, giving me 16 paths, 8 standby, 4 active, 4 active i/o.
 
Well at least we know why now.

And failover works as it should, so sounds like your good to go.
 
Guess it REALLY doesn't matter. I tested the redundancy and know its there I just don't like errors and I consider that an error. plus if someone stupid (i.e. boss) sees it in a demo it just leads to more questions/explanations that could be avoided.

ESX is pretty much considering itself as non-redundant because there is only vmhba33 and not a secondary.
 
from an AUG 2009 doc from VMware-

If we detect less than 2 HBAs or 2 Targets in the paths of the datastore, we mark the datastore multipathing status as “ Partial/No Redundancy “ in the Storage Views .

So key in that is 2 HBAs OR 2 Targets. Well I have more than two targets, I have 4.

Maybe lopoetve will have the answer.
 
Looks like in ESX 4 you can do port binding to the vmhba. doesnt look to be automatic. will keep digging.
 
RiDDLeRThC said:
from an AUG 2009 doc from VMware-

If we detect less than 2 HBAs or 2 Targets in the paths of the datastore, we mark the datastore multipathing status as “ Partial/No Redundancy “ in the Storage Views .

So key in that is 2 HBAs OR 2 Targets. Well I have more than two targets, I have 4.

Maybe lopoetve will have the answer.
Click to expand...

I think you are reading that wrong. If we detect this or this

It seems like you have to fulfill both requirements
1. 2 or more HBAs
2. 2 or more targets
 
Nothing you can do about that. It's how the alarm is calculated.

Requires 2 discrete HBAs, 2 targets. Technically, the software hba is still a singular HBA - it's a single point of failure (although unlikely). The alarm will always show partial right now.

Theoretically, if the software HBA dies (it can be done - kill the vmkload_app, and then rescan a few times), then no matter the pathing, you're down. Realistically, this doesn't happen under any normal circumstance that doesn't also totally hose the host (yay HA!), but nonetheless, that's how the alarm is calculated.
 
So to clarify, RiDDLeRThC meets the target requirement, but not the HBA requirement, so the datastores are still considered "Partial/No Redundancy"?

To meet the HBA requirement, you're saying that he'd need to move to 2 hardware iSCSI initators, as even having path redundancy with a software iSCSI initator is not sufficent?
 
Doesn't seem to make really much sense to me, either an vmware dev oversight (doubt it because its been around for a long time) or something else is in play here that we are missing.

Do that many people run hardware HBA's? I can't see this being the case, lopoetve like you said, if the software HBA isn't working the whole host is most likely down to begin with and there for HA will take over and restore on the other hosts.
 
oDii said:
So to clarify, RiDDLeRThC meets the target requirement, but not the HBA requirement, so the datastores are still considered "Partial/No Redundancy"?

To meet the HBA requirement, you're saying that he'd need to move to 2 hardware iSCSI initators, as even having path redundancy with a software iSCSI initator is not sufficent?
Click to expand...

correct, since technically, the software initiator (no matter the paths) is still a single HBA, and thus a single point of failure (although a bullet proof one).
 
RiDDLeRThC said:
Doesn't seem to make really much sense to me, either an vmware dev oversight (doubt it because its been around for a long time) or something else is in play here that we are missing.

Do that many people run hardware HBA's? I can't see this being the case, lopoetve like you said, if the software HBA isn't working the whole host is most likely down to begin with and there for HA will take over and restore on the other hosts.
Click to expand...

Can't say much of anything there :(
 
lopoetve said:
Can't say much of anything there :(
Click to expand...

Update 2 just came out along with a bunch of other patches. Looking through them it doesn't seem like anything would address this problem. Will patch a test server shortly and see.
 
No, that's software - was new in vSphere. Not required required, but a very good idea. keeps it from using a vmotion interface for iscsi traffic.

Still won't help with this though ;)
 
lopoetve said:
No, that's software - was new in vSphere. Not required required, but a very good idea. keeps it from using a vmotion interface for iscsi traffic.

Still won't help with this though ;)
Click to expand...

I actually send my vmotion traffic over the same network as the iscsi :( I should rework the network so I dont need to.

So I guess for now I need to leave this new feature unconfigured
 
You must log in or register to reply here.
Back
Top