fajarpri
Enthusiast
Enthusiast

iSCSI Luns mapping

Jump to solution

How does ESXi map iSCSI luns to vmfs extends? Reason I ask is I believe it has to do some mapping to make it persistent after a reboot?

Tags (4)
0 Kudos
1 Solution

Accepted Solutions
rickardnobel
Champion
Champion

fajarpri wrote:

@Rikard, similar like that. How does ESX knows that Lun0 goes to extent1 and Lun1 goes to extend2 in that one datastore?

Wouldn't there is possibility that ESX detects Lun1 first than Lun0 and therefore risking mistakenly recognizing it as extent1?

I guess this is somewhat "ESXi internals", but it should be the NAA or T10 number reported from the SAN rather than the LUN id itself which ESXi uses to recognize disks. Since those numbers never change there should be risk of mistakes between reboots. I have a vague memory of this being some kind of issue on the 3.x versions, but should not be these days.

My VMware blog: www.rickardnobel.se

View solution in original post

0 Kudos
6 Replies
rickardnobel
Champion
Champion

fajarpri wrote:

How does ESXi map iSCSI luns to vmfs extends? Reason I ask is I believe it has to do some mapping to make it persistent after a reboot?

Are you asking about when you add another empty LUN to an already existing VMFS datastore?

My VMware blog: www.rickardnobel.se
UmeshAhuja
Commander
Commander

Hi,

Assuming that you want to extend your existing VMFS

Procedure

1 Log in to the vSphere Client and select a host from the Inventory panel.

2 Click the Configuration tab and click Storage.

3 From the Datastores view, select the datastore to increase and click Properties.

4 Click Increase.

5 Select a device from the list of storage devices and clickNext.

Option

Description

Toadd a new extent

Select the device forwhich the Expandable column reads NO.

Toexpand an existing extent

Select the device forwhich the Expandable column reads YES

6 Review the Current Disk Layout to see the available configurations and click Next.

7 Select a configuration option from the bottom panel.

Depending on the current layout of the disk and on your previous selections, the options you see might

Option

Description

Use free space to add new extent

Adds the free space on this disk as a new extent.

Use free space to expand existing extent

Expands an existing extent to a required capacity.

Use free space

Deploys an extent in the remaining free space of the disk. This option is available only when you are adding an extent.

Use all available partitions

Dedicates the entire disk to a single extent. This option is available only when you are adding an extent and when the disk you are formatting is not blank. The disk is reformatted, and the datastores and any data that it contains are erased.

8 Set the capacity for the extent.

The minimum extent size is 1.3GB. By default, the entire free space on the storage device is available.

9 Click Next.

10 Review the proposed layout and the new configuration of your datastore, and click Finish

Thanks n Regards Umesh Ahuja If your query resolved then please consider awarding points by correct or helpful marking.
0 Kudos
fajarpri
Enthusiast
Enthusiast

Thanks. But that's not my question.

Ok let me tell the background info more. Say I create two iSCSI Luns on the Netapp, Lun0 and Lun1. Then I grab this Luns from a Linux system. Linux then recognizes Lun0 as sda and Lun1 as sdb. However it is said that Linux does this recognition during reboot based on completely random chances. So, there is possibility that Lun1 will be recognized first as sda, and vise versa. This is surely not desirable and can cause severe problem depending on the usage of the Luns on the Linux. So one solution is to "map" the Luns statically in Linux (using udev), so no matter which sequence the Luns got detected by Linux during reboot, it will know which Luns go to which sda/sdb.
This got me thinking. Does ESX do some kind of mapping automatically (on multiple iSCSI luns on multiple extents) or not. We can imagine the disaster if it's not and somehow the Luns got mixed up.

@Rikard, similar like that. How does ESX knows that Lun0 goes to extent1 and Lun1 goes to extend2 in that one datastore?

Wouldn't there is possibility that ESX detects Lun1 first than Lun0 and therefore risking mistakenly recognizing it as extent1?

0 Kudos
UmeshAhuja
Commander
Commander

Hi,

You can find the path of the LUN from the below mention link

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100397...

REASON

There are two methods used to obtain the multipath information from the ESX host:
  • ESX command line – use the command line to obtain the multipath information when performing troubleshooting procedures.
  • VMware Infrastructure/vSphere Client – use this option when you are performing system maintenance.

PROCEDURE

ESXi 5.x

Command line

To obtain LUN multipathing information from the ESXi host command line:
  1. Log in to the ESXi host console.
  2. Type esxcli storage core path list to get detailed information regarding the paths. For example:

    fc.5001438005685fb7:5001438005685fb6-fc.5006048c536915af:5006048c536915af-naa.60060480000290301014533030303130
       UID: fc.5001438005685fb7:5001438005685fb6-fc.5006048c536915af:5006048c536915af-naa.60060480000290301014533030303130
       Runtime Name: vmhba1:C0:T0:L0
       Device: naa.60060480000290301014533030303130
       Device Display Name: EMC Fibre Channel Disk (naa.60060480000290301014533030303130)
       Adapter: vmhba1
       Channel: 0
       Target: 0
       LUN: 0
       Plugin: NMP
       State: active
       Transport: fc
       Adapter Identifier: fc.5001438005685fb7:5001438005685fb6
       Target Identifier: fc.5006048c536915af:5006048c536915af
       Adapter Transport Details: WWNN: 50:01:43:80:05:68:5f:b7 WWPN: 50:01:43:80:05:68:5f:b6
       Target Transport Details: WWNN: 50:06:04:8c:53:69:15:af WWPN: 50:06:04:8c:53:69:15:af



  3. Type esxcli storage core path list -d <naaID>  to list the detailed information of the corresponding paths for a specific device.


  4. The command esxcli storage nmp device list lists of LUN multipathing information:

    naa.60060480000290301014533030303130
       Device Display Name: EMC Fibre Channel Disk (naa.60060480000290301014533030303130)
       Storage Array Type: VMW_SATP_SYMM
       Storage Array Type Device Config: SATP VMW_SATP_SYMM does not support device configuration.
       Path Selection Policy: VMW_PSP_FIXED
       Path Selection Policy Device Config: {preferred=vmhba0:C0:T1:L0;current=vmhba0:C0:T1:L0}
       Path Selection Policy Device Custom Config:
       Working Paths: vmhba0:C0:T1:L0


    Note: For information on multipathing and path selection options, see Multipathing policies in ESX/ESXi 4.x and ESXi 5.x (1011340).

vSphere Client

To obtain multipath settings for your storage in vSphere Client:

  1. Select an ESX/ESXi host, and click the Configuration tab.
  2. Click Storage.
  3. Select a datastore or mapped LUN.
  4. Click Properties.
  5. In the Properties dialog, select the desired extent, if necessary.
  6. Click Extent Device > Manage Paths and obtain the paths in the Manage Path dialog.

For information on multipathing options, see Multipathing policies in ESX/ESXi 4.x and ESXi 5.x (1011340)

.

Thanks n Regards Umesh Ahuja If your query resolved then please consider awarding points by correct or helpful marking.
rickardnobel
Champion
Champion

fajarpri wrote:

@Rikard, similar like that. How does ESX knows that Lun0 goes to extent1 and Lun1 goes to extend2 in that one datastore?

Wouldn't there is possibility that ESX detects Lun1 first than Lun0 and therefore risking mistakenly recognizing it as extent1?

I guess this is somewhat "ESXi internals", but it should be the NAA or T10 number reported from the SAN rather than the LUN id itself which ESXi uses to recognize disks. Since those numbers never change there should be risk of mistakes between reboots. I have a vague memory of this being some kind of issue on the 3.x versions, but should not be these days.

My VMware blog: www.rickardnobel.se

View solution in original post

0 Kudos
fajarpri
Enthusiast
Enthusiast

Hi Rikard, thank you.

I have this reply from my regional VMware User Group.

Just for a reply from our storage specialist.
From a LUN perspective, we use NAA id (SCSI identifiers) rather than relying on any controller/target/LUN numbering convention. This way, if the LUNs were presented differently, or were discovered in a different order, we know about them from this NAA id. From a VMFS perspective, both extents would have metadata in their header, but the metadata would identify one datastore as the meta-head and the other extent as just a member.

So looks like there won't be any risk of datastore corruption because of changes in iSCSI Lun sequence recognition.

0 Kudos