2010-05-03 11:24 PM
Check this KB for how to do it:
Solution ID: kb17028
Title: Can I change the LUN type from 'image' to 'linux'?
I believe however that solaris and vmware have the same on-disk format (for alignment purposes) so there wouldn't be any real harm in leaving as-is if migration is undesired.
EDIT: solaris type LUNs have a 1 cylinder prefix so if you format this LUN with VMFS it will be misaligned with regards to WAFL 4k boundries resulting in poorer performance so it would be advised to migrate to newly created LUNs with the proper LUN type.
2010-05-04 05:46 PM
thanks Madden. Looks like we will have to rebuild the VM's.
This does leave me with a couple of other questions.
This problem arrose when an update was appled to the ESX host, causing the VM's to go down. We placed a call with VM who advised that the problem was the LUN Protocol. Reading your post, you indicate that the Solaris and VMWare protocols should be interchangeable. Can you confirm this? (I guess its possible that this was the case before this update was applied and after the update the LUN Protocol became an issue.)
My other question is then, could the LUN Protocol have been changed but some process during the update?
2010-05-04 08:09 PM
The host access is configured in two different places. It's a property of an igroup accessing a LUN, and is a property of the LUN itself. The igroup setting defines how Data ONTAP will present it to the host, things like which SCSI error condition will be returned to the host when a temporary problem prevents access to a LUN, or how it will respond to certain SCSI requests. The LUN type setting defines how Data ONTAP will actually lay out the LUN on disk with things like offsets to ensure data is placed on 4k WAFL boundries, has prefix/suffix to hold extra metadata about how to present the LUN to the host, etc.
If upgrading Data ONTAP any settings will be preserved. If upgrading ESX I can imagine that a mismatch in one of these type settings might result in access problems.
I also did some more research and my earlier statement that alignment was OK as-is is wrong; there is a 1 cylinder offset in the solaris LUN meaning if you format it with VMFS it will not align on 4k WAFL boundries resulting in poorer performance. So it would indeed be wise to migrate the data from the current solaris type LUNs to newly created vmware type LUNs.