RE: ESXi 4 + MD3000i

Networking

ESXi 4 + MD3000i

  • rated by 0 users
  • This post has 9 Replies |
  • 0 Followers
  • Hello,
    We use a PowerEdge R410 with ESXi 4 (build 175625), and a MD3000i array (last firmware).

    The R410 has 4 NICs, as the MD3000i. We have succeeded to configure iSCSI access to storage, with redundant paths. All tests for failover are OK.

    Resume :
    R410
    - vmnic0 and vmnic2 in vSwitch0, for management and vm traffic, with IP 172.16.30.222
    - vmnic1 in vSwitch1, with IP 172.16.31.3
    - vmnic3 in vSwitch2, with IP 172.16.32.3
    - vmnic1 & vmnic3 associated with iSCSI software initiator, Jumbo Frames enabled

    MD3000
    Management ports on 172.16.30.247 & .246
    iSCSI ports :
    Controler 0/0 : 172.16.31.250
    Controler 1/0 : 172.16.31.249
    Controler 0/1 : 172.16.32.250
    Controler 1/1 : 172.16.32.249

    We have only one problem, quite strange. In vSphere GUI, we don't see correctly all the paths to the LUNs. Actually, the paths exist, but the "target" column is filled only for one path on four, the others remain blank, something like that :

    vmhba34:C4:T0:L0 "" (blank)
    vmhba34:C5:T0:L0 "" (blank)
    vmhba34:C6:T0:L0 iqn.1984-05.com.dell:powervault.md3000i.60024e800066b834000000004a5605b5:172.16.32.250:3260
    vmhba34:C7:T0:L0 "" (blank)

    All the iSCSI addresses of the MD3000i are documented in the Static Discovery.

    I don't think it's possible to attach an image on this message, but I can't send it to you, if you want to know more.

    Why can't we see all the target information in the paths ? It's easier to configure all the stuff, the preferred paths, etc.

    Thanks in advance for your help
    Stephane
  • Stephane, need to confirm but it could be an open issue where target information is not fully visible, in VI client interface, for some paths. This should however not impact paths available or connectivity to the array. You can also see the iSCSI session information from the MD3000i Storage Manager (MDSM) application and hence relate the connections from host interfaces to MD3000i ports.
  • Stephane, In an ideal condition, there will be one active path and three standby paths. There is no known issue on this so far. are you seeing the similar behavior in other stup as well. Let me know.
  • "Stephane, need to confirm but it could be an open issue where target information is not fully visible, in VI client interface, for some paths. This should however not impact paths available or connectivity to the array. You can also see the iSCSI session information from the MD3000i Storage Manager (MDSM) application and hence relate the connections from host interfaces to MD3000i ports."
    Thanks for your reply.
    Actually, I can retrieve session information in MSDM, no problem with that. All the sessions are OK. And all the failover tests succeed.
    It seems to be just a display problem.
  • "Stephane, In an ideal condition, there will be one active path and three standby paths. There is no known issue on this so far. are you seeing the similar behavior in other stup as well. Let me know."
    Thanks for your reply.
    We use a "Fixed" policy in VMware to access the LUN.
    On the first server being installed, the display is now correct, I can see all the targets : we have one "Active I/O" path, one "Active", and two "Stand by". It seems correct to me. 12 paths for 3 LUNs with four controllers, normal.
    On the second server installed last week (same configuration), the display is incorrect.
    There is the same display failure, only one path with target full information, the others are blank. And we see 16 paths, because the host sees the 31 LUN. Strange.
    I have to set up the third and last server this week, I will let you know if there is the same behavior.
  • "We use a "Fixed" policy in VMware to access the LUN.
    "
    Are there any Dell recommendations as whether to use fixed, MRU or Round Robin against an MD3000i? Does one also need to correlate the MSDM "preferred owner" policy with the preferred path in ESX?
  • "Thanks for your reply.
    We use a "Fixed" policy in VMware to access the LUN.
    On the first server being installed, the display is now correct, I can see all the targets : we have one "Active I/O" path, one "Active", and two "Stand by". It seems correct to me. 12 paths for 3 LUNs with four controllers, normal.
    On the second server installed last week (same configuration), the display is incorrect.
    There is the same display failure, only one path with target full information, the others are blank. And we see 16 paths, because the host sees the 31 LUN. Strange.
    I have to set up the third and last server this week, I will let you know if there is the same behavior."
    Hello,
    As said before, I've installed a third server this week. And the problem is still there : in vSphere, no correct display of all the target paths.
    In resume, 3 servers, 2 incorrects. It's even worse on the last server installed, because the controller numerotation (vmhba34:C4:T0:L0) is not the same as the others servers.
    Do you know if the problem comes from Dell or VMware ? Perhaps I could open an issue with VMware support.
    Thanks in advance for your reply.
  • "Are there any Dell recommendations as whether to use fixed, MRU or Round Robin against an MD3000i? Does one also need to correlate the MSDM "preferred owner" policy with the preferred path in ESX?"
    I don't know for Dell recommendation, but the Fixed policy is explained in VMware SAN Guide, apparently default policy for active-active array, and recommended for load balance LUNs access.
    And, yes, in my case, I had to match the Preferred owner on the array, and the Fixed path in vSphere on the same controller (so it's difficult to do that without the target paths information).
  • "Stephane, need to confirm but it could be an open issue where target information is not fully visible, in VI client interface, for some paths. This should however not impact paths available or connectivity to the array. You can also see the iSCSI session information from the MD3000i Storage Manager (MDSM) application and hence relate the connections from host interfaces to MD3000i ports."
    Hello,

    Do you have any clue for me ? Should I open an incident for that with the support ?

    TIA
  • @Hpets,

    I would recommend opening a support issue with VMware support first. They will pull in Dell product support as needed. Please update your status here. If you run into a roadblock with support, send me a DM.

    Thanks,

    KongY@Dell
Page 1 of 1 (10 items)