Export Virtual Volume

[guz2014]

I need someone to explain to me when and when not to use the "Auto" check box under "Export with LUN value" option.

Plus, I exported three VV and they all show LUN 0. Why?

[nsnidanko]

My guess because VV -> Host relationship is different for each VV. Each VV is exported to a different host or group of hosts.

[hdtvguy]

I use auto all the time. The only time I do not is when I want to assure a VV gets the same LUN Id for hosts in different clusters. An example is for our vmware we have 7 clusters and we have a common SRM volume and then a volume with templates that is shared across all clusters. we manually assign one ID 253 and the other 252 when we export it to each cluster. This is NOT a vmware requirement, but does keep things simple. If you are exporting to host sets then I find auto is fine. I am sure there are some OSes that want all volumes to be identical ID, but I think that is rare. VMware I believe only cares that a volume have same ID when it is present to all hosts in a given cluster, but you can have a volume exported with one ID to one cluster and the same volume with another ID to another.

Auto is less of issue than exported VV sets. Avoid exporting VV sets at all cost. When exporting VV sets the volumes in the vvset will be given sequential IDs and then you run into issues if you delete volumes in the future and add more. Also if you export a VV set to one host set then try to export it to another the array wants to use the same exact lun ID in each export, that woudl casue a problem if any of those ID s are already in use by the additional host set you export the vv set to.

[Richard Siemers]

Each host can have one LUN 0 assigned to it per storage controller. If you had two 3PAR systems attached to 1 host, he could have two LUN 0, but as you can imagine that could cause some identification complexity with some hosts/OSes.

I leave auto on when:
Assigning a lun to a single stand alone host, connected to only 1 storage system.

I turn auto off when:
When complexity requires advanced labeling,
On hosts attached to multiple 3PARs, we use LUN 0-99 for one and 100+ for the other.
On ESX clusters (one 3par dedicated to ESX) we use LUNs 0-99 for Prod, and LUNs 100+ for Dev.
On MS-SQL where we have a special request for 1 node only to get a LUN, we will assign this one off starting at 100, so that the auto will continue to work correctly when assigning to the host set.

[guz2014]

Each host can have one LUN 0 assigned to it per storage controller. If you had two 3PAR systems attached to 1 host, he could have two LUN 0, but as you can imagine that could cause some identification complexity with some hosts/OSes.

I leave auto on when:
Assigning a lun to a single stand alone host, connected to only 1 storage system.

I turn auto off when:
When complexity requires advanced labeling,
On hosts attached to multiple 3PARs, we use LUN 0-99 for one and 100+ for the other.
On ESX clusters (one 3par dedicated to ESX) we use LUNs 0-99 for Prod, and LUNs 100+ for Dev.
On MS-SQL where we have a special request for 1 node only to get a LUN, we will assign this one off starting at 100, so that the auto will continue to work correctly when assigning to the host set.

Thanks you Richard

[guz2014]

I use auto all the time. The only time I do not is when I want to assure a VV gets the same LUN Id for hosts in different clusters. An example is for our vmware we have 7 clusters and we have a common SRM volume and then a volume with templates that is shared across all clusters. we manually assign one ID 253 and the other 252 when we export it to each cluster. This is NOT a vmware requirement, but does keep things simple. If you are exporting to host sets then I find auto is fine. I am sure there are some OSes that want all volumes to be identical ID, but I think that is rare. VMware I believe only cares that a volume have same ID when it is present to all hosts in a given cluster, but you can have a volume exported with one ID to one cluster and the same volume with another ID to another.

Auto is less of issue than exported VV sets. Avoid exporting VV sets at all cost. When exporting VV sets the volumes in the vvset will be given sequential IDs and then you run into issues if you delete volumes in the future and add more. Also if you export a VV set to one host set then try to export it to another the array wants to use the same exact lun ID in each export, that woudl casue a problem if any of those ID s are already in use by the additional host set you export the vv set to.

Thank you

[guz2014]

My guess because VV -> Host relationship is different for each VV. Each VV is exported to a different host or group of hosts.

Thank you