Project

General

Profile

Bug #15114

9.3 upgrade to 9.10 iSCSI LUNs in VMware show as Snapshot LUNS

Added by Tyler Todd over 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
No priority
Assignee:
Alexander Motin
Category:
OS
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

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?

History

#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).

#5 Updated by Shane Slocum almost 3 years ago

This seems to be the same issues as is being seen in bug #14331

I am still seeing this issue and stuck on 9.3 until it is resolved.

#6 Updated by stan stan almost 3 years ago

SSH to esxi server
esxcfg-volume -l
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 almost 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.

#8 Updated by Vaibhav Chauhan almost 3 years ago

  • Target version set to 9.10.2

#9 Updated by Alexander Motin almost 3 years ago

  • Status changed from Investigation to Resolved

Lets assume that problem was in using auto LUN numbering in 9.3. It was removed in 9.10, so hopefully this should no longer be a problem.

Also available in: Atom PDF