iSCSI Datastore Extend
Have a question posted by one of my customer on iSCSI datastore extend.
In Linux, if you have two LUN created every time this machine is rebooted, sometimes the LUNs get mixed up e.g. sda for LUN1 and sdb for LUN2 which could be vice versus unless a udev is used to statically map the drive to ensure the path remains the same.
So now if we compare that in ESX, if we reboot an ESX server which has two LUN of iSCSI datastore which one extend to the other, would this cause any confusion placing the 2nd extend to be the 1st extend of datastore? If not, how does ESX know the iSCSI datastore extended order?
I wasn't able to answer this and got reply from Cormac Hogan in VMware.
No – no confusion would occur.
From a LUN perspective, vSphere uses 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 extends 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.
We have many customer using iSCSI extents, and they work perfectly fine.
There you have it. Very interesting question and concept on how it work out in vSphere.
In Linux, if you have two LUN created every time this machine is rebooted, sometimes the LUNs get mixed up e.g. sda for LUN1 and sdb for LUN2 which could be vice versus unless a udev is used to statically map the drive to ensure the path remains the same.
So now if we compare that in ESX, if we reboot an ESX server which has two LUN of iSCSI datastore which one extend to the other, would this cause any confusion placing the 2nd extend to be the 1st extend of datastore? If not, how does ESX know the iSCSI datastore extended order?
I wasn't able to answer this and got reply from Cormac Hogan in VMware.
No – no confusion would occur.
From a LUN perspective, vSphere uses 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 extends 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.
We have many customer using iSCSI extents, and they work perfectly fine.
There you have it. Very interesting question and concept on how it work out in vSphere.
Comments