9.3 upgrade to 9.10 iSCSI LUNs in VMware show as Snapshot LUNS
After upgrading from 9.3 to 9.10, my LUNs did not reconnect in VMware. When I went to add the storage, they were there and when chosen to connect, the only option i was given was to format. Since VMware detected these as snapshot LUNs, i force mounted them on each host. No issue present until I went to extend the LUN. I extended no issue within FreeNAS, but VMware will not allow it since its a snapshot LUN.
I do not have snapshots of the ZFS pool tied into the VMware snapshots.
Why were the LUNs changed on FreeNAS post upgrade to 9.10 to cause this behavior?
#1 Updated by Alexander Motin over 3 years ago
- Status changed from Unscreened to Screened
VMware detects LUNs as snapshots in case of some LUN identification change. There should nothing change between 9.3 and 9.10 in that way. My only guess is that you were using automatic LUN allocation in your iSCSI settings, and for some reason LUN IDs has shifted. In that case I would recommend you to hardcode LUN numbers there instead of using "Auto".
#2 Updated by Tyler Todd over 3 years ago
I wouldn't count this as a 1-off issue if its happened across multiple upgrades from 9.3 to 9.10. This has happened on 2 other FreeNAS boxes as well. While yes, they are set to auto, i didn't have issues upgrading from 9.2 to 9.3 and then any release of 9.3. It should be worth checking or noting this for upgrade paths to 9.10, or why the LUN IDs are changed in auto mode from 9.3 to 9.10.
#3 Updated by Tyler Todd over 3 years ago
- Seen in changed from 9.10-STABLE-201604181743 to 9.10-STABLE-201605021851
And now that I review the VMware side, all LUNs are 0, as the targets are different. Each Extent on FreeNAS has its own associated target. I just also created a new FreeNAS box and went from 9.3 to 9.10 for testing. The LUN ID was set to 0, and the upgrade was performed to 9.10. Went to VMware and it was detected as a snapshot after the upgrade. The NAA in VMware stayed the same and the serial within FreeNAS stayed the same, along with the Target and LUN within VMware. VMware is ESXi 6.0. The base has not changed in the FreeNAS Target Global Configuration.
#4 Updated by Jordan Hubbard over 3 years ago
- Status changed from Screened to Investigation
BRB: There definitely appears to be some weird interaction between auto / static assignments and upgrades, and we have some theories about how we might work-around this, but we need to do some test upgrades of our own first to see if we can even reproduce this (we have done a lot of VMWare server upgrades from 9.3->9.10 without incident).
#6 Updated by stan stan over 3 years ago
SSH to esxi server
u can see like this:
VMFS3 UUID/label: 5191aacb-0123ec38-d197-b499baafae33/ESX-Data-1 Can mount: Yes Can resignature: No (the volume is being actively used) Extent name: eui.cd8f68cd8447778c:1 range: 0 – 1023743 (MB)
esxcfg-volume -m ESX-Data-1
#7 Updated by Shane Slocum over 3 years ago
Thanks. Thank helped me find the following VMware KB. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011387
Something with the upgrade seems to be changing the addressing or signature such that ESX thinks it must be a snapshot. The workaround is easy, but I was nervous to walk through the add storage wizard until I found the KB, for fear of overwriting my data.
Currently running 9.10 and seems to be working as expected after that procedure.