• 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.

Let's talk about vmkping shall we?

Vader

Supreme [H]ardness
2FA
Joined
Dec 22, 2002
Messages
5,137
I came upon a vSphere deployment recently where the iSCSI port bindings were not configured. I went to configure them on both hosts and the expected number of paths on the second host was not right.

I validated everything, tore it down, set it back up, identical to Host1.

I then proceeded to do some vmkpings specifying both vmkernals bound to their respected interface.

Pings came back fine. Even went as far as updating the drivers on the NIC's etc.

I get on the phone with VMware and now they are telling me that sometimes even when you do a vmkping -I and select the vmk it could still go out the only working vmk?

Really? WTF good is vmkping then...especially when you are binding vmk's to physical uplinks?

Curious to see what you guys/gals think about that explanation..and if it's valid?
 
Sounds like a possible mistruth or something is broke like a joke. Subscribing.
 
It has to do with how the kernel handles ICMP traffic >_<

Should be fixed for good in 5.5, cropped up a few times prior.

Oh, and you can just use ping now - we aliased it. :)

that being said, the vmkernel log should note what the failure was - did you have paths BEFORE the binding? If so, it won't "drop" the now invalid ones till you reboot (in case you screwed up), so a reboot may be needed to really see what it "sees".

What's the array?
 
The Host was rebooted, and it didn't have bindings so no multipath configurations. We received a call to help a customer with other issues in their Virtual Environment, and this is how I found it, which is typical btw. I really should just start my own consulting business to fix current vSphere environments..lol.

Anyway, I was using vmkping -I to choose the vmk interface so I can send it out the correct uplink. The next test was proof of what your saying lopoetve, because when I removed the working vmk binding I couldn't ping out of the remaining vmk-uplink even though it "worked" when I chose it when both were bound, which stumped me because everything i've read says that I can use vmkping with the -I to select the vmk interface I want to ping from. Turns out that interface never worked because it was on the wrong VLAN in the switch.

The array is an EqualLogic PS4000.

I have another question as well. This is the third time i've run into a customer that was an upgrade to 5.x from a 4.x environment. All three times iSCSI port bindings were not set at all. When we used to do it via CLI and you upgrade, will it/shouldn't it retain those bindings in the Software iSCSI adapter in Network Configuration?
 
Last edited:
Yeah, the EQL - you need 3 ports per 2 nics - one bound per, and the floating heartbeat port (the first one) to respond to pings from the array (that ICMP issue).

As for ping - it "sorta" works. the interface will send it, but it won't be the one ~receiving~ it... It's odd >_< Fixed in 5.5!

Yes, the bindings should carry for an upgrade. I haven't tested it in ages though :p
 
that being said, the vmkernel log should note what the failure was - did you have paths BEFORE the binding? If so, it won't "drop" the now invalid ones till you reboot (in case you screwed up), so a reboot may be needed to really see what it "sees".

What's the array?

Okay. I meant to ask you about that a while back. I noticed that behavior and thought that. Thanks.
 
Okay. I meant to ask you about that a while back. I noticed that behavior and thought that. Thanks.

There was a brief period (might not have made it out) that it did it... suffice to say, that would have been a "bad" idea.
 
Supposedly the Heartbeat Port Group is no longer needed with Equallogic Arrays and vSphere 5.1, I havent been using it and have had no issues with failovers.

Here was the original issue and reasoning
http://kb.vmware.com/selfservice/mi...nguage=en_US&cmd=displayKC&externalId=2007829

I've heard that, and there's a bit more to it than that. I'll investigate to see if all the issues were fixed or not.

Lemme put it this way - having it can't hurt, if you have the IP to spare ;)
 
Back
Top