iSCSI Multipathing

Similar Questions

• iSCSI multipath vs network redundancy?

  If I have a redundant network, say a VMkernel port on a vSwitch with two VMnic, maybe Port ID load balancing and the two vmnic goes to two different physical switches and there are redundant links on all switches between the ESXi host and iSCSI SAN and it is Rapid Spanning Tree set up, and there is a kind of Etherchannel / Link aggregation on the iSCSI Server , but only a single IP address...

  Is there an advantage to configuring iSCSI multipath and let the VMkernel manage failover, rather than let the network itself, make sure that there is a path between the host and the target?

  Primary storage provider use several IP for storage NIC (in some cases two different networks).

  With the VMware multichannel modules, you are limited to only one path (at that moment) to a LUN, but the seller might have is multichannel modules, or of course, you can use LUN more have used more of paths.

  Bandwidth could be interesting with several virtual machines... or I/O loads.

  André

• Why several vmkernels for iSCSI multipath?

  I'm a little confused about the iSCSI Multipathing. What is the reason for the creation of two vmkernel interfaces and then use command line tools to link them to a new vmhba? Is it different for the use of a software iSCSI initator on a vSwitch with multiple VMNIC, connected to different physical switches?

  There is the same discussion in thread Russian vmug.

  iSCSI Multipathing is not on the trail, its about us pairs - initiators (interfaces vmk) and targets.

  If you have two targets

  • and you need to fail over only - 1 vmk is enough (NIC in Active mode / standby)
  • If you need loadbalacing
    • and you can use the aggregation of links + Hash IP - 1 vmk is sufficient (PSP is Roundrobin and NICs in active/active mode)
    • If you cannot use THE - vmk 2 are needed.

• iSCSI multipath on a distributed vSwitch?

  I read that there are problems with this and I'm pretty positive, I read that it is still not supported in one of the documents ESX4u1 (although for the life of me I can't find this text of presentation this morning).  Is this even a question?  And if so, can someone explain why exactly this is not working?

  I'm documenting a config proposed for deployment using cards dual 10GbE and I do research using iSCSI multipath and dvSwitches.  Which raises another question, on a channel 10GbE same multipathing necessary?

  
  
  -Justin

  If you are talking about the use of links in the port, then you must use conventional switches for this purpose.  It is in the notes version of vSphere

  vExpert

  VMware communities moderator

  -KjB

• iSCSI multipath with Distributed Virtual Switch error

  Ive followed the iSCSI SAN guide and have iSCSI multipathing works well with a regular virtual switch. Ive cancelled all configurations and have begun to see if I can get this working with a dVSwitch.

  I get the error "Add Nic failed in IMA"

  Someone at - it ideas?

  I recently worked on a case of iSCSI with VMware support and they mentioned a known issue with iSCSI and dVS, this is also described in the release notes, but may still have a problem. You can contact the technical support for confirmation.

  • ESX/ESXi 4.0 4.0 does not support the compatible ports with DVS binding configuration VMkernel network interface cards

  If you configure compatible with vNetwork Distributed Switch port binding NICs VMkernel, the operation fails if you enter esxcli swiscsi nic adds - n vmkx d vmhbaxx and vmkiscsi-tool - V - a vmkx vmhbaxx orders through the service console or the vSphere CLI.

  Workaround: Use only inherited vSwitch VMkernel NIC for port binding.

  =========================================================================

  William Lam

  VMware vExpert 2009

  Scripts for VMware ESX/ESXi and resources at: http://engineering.ucsb.edu/~duonglt/vmware/

  repository scripts vGhetto

  VMware Code Central - Scripts/code samples for developers and administrators

  http://Twitter.com/lamw

  If you find this information useful, please give points to "correct" or "useful".

• Reduce the number of iSCSI Multipathing in paths

  I'm experimenting with performance iSCSI on NAS. Currently I have 4 NICs on the host and 4 NICs on the NAS. That leaves me with 16 channels for iSCSI data store. I would like to disable multipathing so I find myself with 4 paths. I would try having NIC1 on the host go on the NAS NIC1 and NIC2 on the host then goes to NIC2 on the NAS, so on and so forth. Is this possible? I saw that I could disable paths but I did anyway to say which way goes to which nic so that I might finish with 4 paths all on the same network adapter. Any help would be appreciated.

  I found that if I broke to the top of each of the 4 NIC I used for iSCSI in different subnets traffic and then set the 4 network cards on the NAS in the same subnets I could get the number of paths down to 4. However with adapter for iSCSI for the VMware software there is no way to have more than 1 NIC of the flow value. Round Robin will use only 1 NETWORK with a value of debit card while I was stuck with the help of only 25% of the potential flow of the NAS for iSCSI traffic.

• iSCSI Multipathing - each path does refer to a specific target IP address?

  Dear Experts,

  I just set up a 6.0 ESXi host and a Synology NAS ds2015xs MPIO Multipathing. On the side of ESXi, I created two dedicated VMkernel with a physical NIC adapters each and every other network cards set to unused. I then added the adapters to the software iSCSI adapter in ESXi. On the side of SIN, I configured both interfaces in the same subnet as the VMkernel adapters. I then created a target which allows multiple iSCSI sessions, add LUNS and allowed access to the target for the IQN of the ESXi iSCSI Software adapter name.

  Back on the side of ESXi, I added a static discovery entry manually adding addresses to IP of NAS devices and target IQN. After a new analysis of the storage, ESXi showed two paths to the interface of the SIN for which I entered the IP address as a static discovery entry:

  

  With this configuration, multiple paths does not--once to stop the interface on the NAS, ESXi don't miss not automatically during the second interface of the NAS. After you have added a second static discovery entry with specifying the same target, but the second IP address of the NAS, ESXi showed all four lanes - two at each interface on the NAS:

  

  With this configuration, Multipathing works as expected. If an interface on the NAS fails, ESXi will automatically use a path for the second interface.

  In fact, it makes sense. At first, I was wondering about whether it is correct that I have to manually enter each interface of the target in order to obtain the corresponding paths to it. I first thought that I just need to enter an IP address of the target and that MPIO uses a kind of magic to automatically discover the paths to other interfaces available on the NAS. Later, I saw that this is the case when using dynamic discovery instead of static discovery. However, the same dynamic discovery adds all interfaces of the SIN as entries in static discovery. Once I have delete one of these entries in the list, the corresponding paths are also deleted.

  So my correct understanding that always information path refers to the corresponding IP address of the target and that a way will stop working once the corresponding IP address is no longer available?

  Thank you

  Michael

  When you configure access to storage, it is always important to follow the recommendations of the supplier. Not only to learn how the program setup the IP configuration, but also for the way political (e.g. Fixed, MRU, Round-Robin).

  Regarding your question, many storage arrays are configured with the extra VIP (virtual IP address) or IP address of the group, which is then used to configure the target (or another) dynamic on the ESXi hosts. When an initiator connects to such a VIP or group IP, the target will respond with all of its associated IP addresses. If this isn't an option for your storage device, you must provide all the IPS target manually (as you did).

  André

• iSCSI Multipathing - really useful?

  Suppose to have this configuration:

  2 ESXi host-> HP DL380 G7 (4 x 1 Gbit NIC + 2 x 10 Gbit NIC)

  1 storage-> MSA P2000 (2 x 1 Gbit NIC + 4 x 10 Gbit NIC)

  The two hosts will be connected to the storage through 10 Gbit adapter. Since no 10 Gbit switch is available, guests will be DIRECTLY connected to the storage.

  Multipathing is always necessary in this case? I mean, I can understand, multiple paths is very useful if you have several path to reach the storage (multiple switch with a network different for examples). But in this case, if for example a 10 Gbit card on one server will be lost, I would therefore lost two way.

  Am I wrong?

  Is 4 x 10 GbE NIC on storing a single NETWORK card? Otherwise, you can cross the cables from hosts to it and have a warranty from the point of view of the moribund NIC storage.

  Since I read your post tos ay that the cards 2 x 10 GbE NIC on the hosts are a single card, and if storage 4 x 10 GbE NIC is also a unique card, while the only reason for multipath would be to have access to the additional uplinks to a higher throughput of iSCSI.

  I would consider using the 1GbE NIC as an uplink ensures 10GbE links to help prevent single points of failure.

• iSCSI Multipathing vs just make the NICs active/active (vSphere)

  Hello

  I have 2 physical cards in my iSCSI vSwitch for dedicated and I understand that if I want to use multipathing I need to create 2 VMKernel ports, assign to each NETWORK adapter and connect them to the iSCSI initiator using the CLI interface.

  It is, what are the benefits this new management feature gives multichannel just teaming network adapters in an Active / Active configuration? The two configurations are not only as redundant ones than the others?

  Thank you

  Pete

  MPIO allows a server with multiple NICs for transmitting and receiving of I/O across all interfaces available in a compatible SAN corresponding MPIO.  If a server had four 1 GB/s network adapters and SAN had four 1 GB/s network adapters, the theoretical maximum rate would be about 400 MB/s (3.2 Gbit/s).

  Aggregation by grouping NETWORK adapters (or LACP, PAgP, 802.3ad, etc.) doesn't work the same way. Aggregation of links does not improve the throughput of a single traffic flow (a single source of communication with a single destination).  Only one stream will always travel the SAME path.

  The advantage of the aggregation of links is seen when several 'unique' streams (each with different source / destination) exist.  Each individual stream is sent down from its own available NETWORK adapter interface (computed by a hash algorithm).  Most unique feeds, most used network cards, more view aggregate throughput achieved. Aggregation of links will not improve throughput for iSCSI, although it gives a degree of redundancy.

  I hope this helps.

  Paul

• Problems with iSCSI Multipath i/o

  Hi people,

  I just started testing with ESXi 4 and hit a snag with the software iSCSI adapter and Multipath i/o.

  A bit of background reading, I understand that the storage architecture is a little different to 3.5, with the new PUBLIC service announcement.

  Anyway, here's the implementation.

  Single host ESXi 4.0

  -vSwitch1

  -Two cards of uplink physical

  -Two ports, with a VMKernel interface in each group (see attachment "Storage4 - Network.jpg'")

  -10.42.80.107 & 10.42.80.108

  -L' order of the adapter has been supplanted in the port groups while only 1 adapter is active in two groups of offices

  -Added the two interfaces VMKernel (vmk1 & vmk2) for iSCSI adapter, using the commands 'esxcli nic swiscsi.

  -Basically, everything described in the VMWare "iSCSI SAN Configuration Guide"

  Thecus R4500i iSCSI SAN

  -Two physical network adapters

  -Each physical NETWORK card has it's own IP address

  -10.42.80.200 & 10.42.80.201

  So in this configuration, I should end up with 4 paths:

  ESXi 10.42.80.107 - SAN 10.42.80.200

  ESXi 10.42.80.107 - SAN 10.42.80.201

  ESXi 10.42.80.108 - SAN 10.42.80.200

  ESXi 10.42.80.108 - SAN 10.42.80.201

  That is what I get, if I look in the "Configuration\Storage Adaptors\iSCSI software adapter" (see attachment "Storage2 - Paths.jpg'").

  But here's the problem, when I take a look in "Configuration\Storage\Devices\iSCSI Software Adaptor\Manage paths", I get only one path (see attached "Storage3 - Paths.jpg").

  Can someone help explain this? Did I miss something?

  This same configuration (servers, network cards, SAN, etc.) everything is perfect with multiple paths in ESXi 3.5

  (And Yes, I know that the Thecus ' "is not on the HCL supported, but we are only talking about standard iSCSI here, no additional Plugins storage, etc.)

  Not uber-urgent, but annoying, as this lack of multipathing would stop a vSphere deployment.

  Thank you

  Graham.

  Looking at the trace, it seems that, the table is not confirming to the specification when it sends data VPD. Let's not id NAA format. According to "spc3r23, 7.6.3.6.1 basic format of identifier NAA", the first Quartet of the NAA id can be 0 x 2, 0 x 5 or 0 x 6. However, the trace shows 0 x 9. ESX 4.0 does not have several paths to the LUN b ' cos of this. Is there a way to disable 'Page of Identification of device' on the side table.

• Clarrion AX4 EMC Bay (ISCSI Multipathing subnets)

  I just wanted to get a quick clarification of people with the introduction of an array of Clarrion EMC.  The array has two storage processors, each processor has two 1 GB interfaces.  If the look of config like:

  SPA1 - SUBNET1

  SPA2 - SUBNET2

  SPB1 - SUBNET1

  SPB2 - SUBNET2

  or

  SPA1 - SUBNET1

  SPA2 - SUBNET1

  SPB1 - SUBNET2

  SPB2 - SUBNET2

  Trying to figure out which one is correct?

  It s a while now, I have install a Clarrion with iSCSI, but I m pretty sure that it's:

  SPA1 - SUBNET1

  SPA2 - SUBNET2

  SPB1 - SUBNET1

  SPB2 - SUBNET2

  If I remember there was also a good documentation in the manuals that shipped with the correct Clarrion.

  Kind regards

  Mario

• iSCSI Multipathing - interesting questions

  Hi all

  Here is the scenario, I have an ESXi4.1 environment. I had 4 servers ESXi and vCenter server. I need to configure the iSCSI. I use a NetApp box for this. I create vSwitch which I create a VMkernel port and assign an IP address that is in the same subnet as NetApp box. I give this all active vSwitch 4 network cards and then activate the s/w iSCSI initiator. I am able to communicate with the NetApp box. now the question is through which nic I am communicating to the BOX iSCSI?

  What happens if one of the this vSwitch vmnic fails?

  Can I configure the aggregation of links for this configuration with a single port VMkernel, it balances the load in this case?

  For iSCSI, I do not recommend to use the aggregation of links, but to set up the network, in the right way (and as suggested by the storage for vSphere provider) to use MPIO.

  NIC working? Generally, one for each LUN... (so more LUNS are a good idea).

  André

• Can someone explain how to configure iSCSI multipathing software iSCSI?

  I have two physical network adapters, dedicated to a vswitch iSCSI and I created a second VMkernel port, but don't know what to do next to make sure I have redundancy through multiple paths?

  It depends on your type of storage.

  If used if two different iSCSI network (such as the AXE, MD3000i,...) you must set 2 different vSwitches, for each network and add all 4 of your target to the iSCSI initiator.

  If she used a flat (like Equallogic) iSCSI network you must use 1 vSwitch with at least 2 physical NETWORK adapter and 2 vmkernel interface and bind each interface to a network card.

  See page 33 of the:

  http://www.VMware.com/PDF/vSphere4/R40/vsp_40_iscsi_san_cfg.PDF

  André

• iSCSI / vmkernel multipathing vs NIC teaming

  Hello

  I know of Configuration of VMware SAN Guide provides information about how to configure iSCSI multipath with vmkernel interfaces double on various uplinks.

  What are the disadvantages of using basic NIC teaming instead? Just an interface of vmkernel on a vswitch (d) with two uplinks. It will work properly about redundancy and failover?

  Kind regards

  GreyhoundHH wrote:

  What are the disadvantages of using basic NIC teaming instead? Just an interface of vmkernel on a vswitch (d) with two uplinks. It will work properly about redundancy and failover?

  I guess the difference is while using "Port Binding" iSCSI initiator uses vSphere Pluggable Storage Architecture to handle the load balancing/redundancy, that can make better use of multiple paths to NETWORK card available. Otherwise, the initiator will use vmkernel stack ensures redundancy network and balancing in the same way as a normal network traffic.

  I suggest that you look at the great post on iSCSI multi-vendor, I think the 2 statements below will summarize the difference:

  "

  • However, the biggest gain of performance allows the storage system to scale the number of network adapters available on the system. The idea is that multiple paths to the storage system can make better use multiple paths, he has at his disposal than the consolidation of NETWORK cards on the network layer.
  • If each physical NETWORK adapter on the system looks like a port to a path to the storage, the storage path selection policies can make best use of them.

  "

  
  

• iSCSI MPIO (Multipath) with Nexus 1000v

  Anyone out there have iSCSI MPIO successfully with Nexus 1000v? I followed the Cisco's Guide to the best of my knowledge and I tried a number of other configurations without success - vSphere always displays the same number of paths as it shows the targets.

  The Cisco document reads as follows:

  Before you begin the procedures in this section, you must know or follow these steps.

  •You have already configured the host with the channel with a port that includes two or more physical network cards.

  •You have already created the VMware kernel NIC to access the external SAN storage.

  •A Vmware Kernel NIC can be pinned or assigned to a physical network card.

  •A physical NETWORK card may have several cards pinned VMware core network or assigned.

  That means 'a core of Vmware NIC can be pinned or assigned to a physical NIC' average regarding the Nexus 1000v? I know how to pin a physical NIC with vDS standard, but how does it work with 1000v? The only thing associated with "pin" I could find inside 1000v was with port channel subgroups. I tried to create a channel of port with manuals subgroups, assigning values of sub-sub-group-id for each uplink, then assign an id pinned to my two VMkernel port profiles (and directly to ports vEthernet as well). But that doesn't seem to work for me

  I can ping both the iSCSI ports VMkernel from the switch upstream and inside the VSM, so I know Layer 3 connectivity is here. A strange thing, however, is that I see only one of the two addresses MAC VMkernel related on the switch upstream. Both addresses show depending on the inside of the VSM.

  What I'm missing here?

  Just to close the loop in case someone stumbles across this thread.

  In fact, it is a bug on the Cisco Nexus 1000v. The bug is only relevant to the ESX host that have been fixed in 4.0u2 (and now 4.1). Around short term work is again rev to 4.0u1. Medium-term correction will be integrated into a maintenance for the Nexus 1000V version.

  Our implementation of code to get the multipath iSCSI news was bad but allowed in 4.0U1. 4.0U2 no longer our poor implementation.

  For iSCSI multipath and N1KV remain 4.0U1 until we have a version of maintenance for the Nexus 1000V