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.
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?
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. 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?
Hi,
You can find the path of the LUN from the below mention link
REASON
PROCEDURE
To obtain multipath settings for your storage in vSphere Client:
For information on multipathing options, see Multipathing policies in ESX/ESXi 4.x and ESXi 5.x (1011340)
.
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.
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.