Just upgraded to 2.30.DB00000000.2820 and see a few "wierd" things with ESX 3.02...

Configuration:

1 VG (vg00), 4 logical volumes (lv0000 (pre 2.30 upgrade), lv0001-lv0003 (after upgrade)
3 targets (vm01-vm03)
lv0000 = LUN 0 in vm01 (250GB)
lv0001 = LUN 1 in vm01 (500GB)
lv0002 = LUN 3 in vm02 (450GB)
lv0003 = LUN 0 in vm03 (50GB)


Problem #1
-------------

Looking at this setup from VMware (Configuration, Storage Adapters, Details)

Target 0 - vm01 - 2 LUNS, 250GB (LUN 0) and 500 GB (LUN 1) - As expected
Target 1 - vm02 - 2 LUNS, 250GB (LUN 0) and 450 GB (LUN 3) - Didn't expect a "LUN 0"
Target 2 - vm03 - 1 LUN, 250GB (LUN 0) - Didn't expect it to be 250GB

So there are two issues

1. "LUN 0" is every target and is being set to the 250GB LV
2. The first LUN # -> LV mapping "wins" if the LUN # is used in another target (i.e. LUN 0 is used in vm01 and set to lv0000, and when LUN 0 is used in vm03 and set to lv0003, it is "overridden" and LV0000 appears instead)

Looking a bit deeper it seems that "Path" and "Canonical Path" are different in the ESX storage adapter details page


____________Path________Canonical Path
Target 0 - vmhba40:0:0.____vmhba40:0:0
_________vmhba40:0:1____vmhba40:0:1

Target 1 - vmhba40:1:0____vmhba40:0:0________Huh? No LUN 0 in this target
________vmhba40:1:3____vmhba40:1:3

Target 2 - vmhba40:2:0____vmhba40:0:0________Huh? Using target 0's LUN 0 instead of 3's

So the basic result is under ESX 3.02 the LUN numbers must be globally unique, which is not true under the Windows Vista iSCSI initiator. Not a big deal to keep the LUNs globally unique, just unexpected...


Problem #2
-------------

A "new" lv will cause an error when attempting to add storage. On the "Current Disk Layout" step the error "Unable to read partition information from this disk" will be returned. You must then create a partition on this disk using Windows or fdisk from the ESX console session. Using

fdisk /vmfs/devices/disks/vmhba40\:0\:1\:0

to create the partition will show a warning saying

"Invalid flag 0x0000 of partition table 4 will be corrected by w(rite)"


This seems to be a new "extra step required" since upgrading from 2.21 to 2.30; not sure if 2.21 actually put some kind of partition in there, or just didn't write the "invalid" 0 in there...


Anyway, just my observations so far...

Craig