ESXi 5.5 / StarWind Disk Resignature issue

[SayNo2HyperV]

Had ESXi connected to StarWind v6 via iSCSI MPIO.

Upgraded to Starwind v8.  Upgrade went fine...all existing disks/targets remained and ESXi host had all volumes mounted. 

At the same time of upgrade I wanted to change the RAM cache in Starwind for each of my virtual devices.  Unfortunately Starwind does have have this built in for existing devices. I did find mention of editing the .swdsk file to set the cache.  However my upgraded Starwind was not using this Virtual disk format.

So...I deleted a existing virtual device without deleting it's related image file.  Re-created Starwind Device/virtual disk.  Attached existing image file.  Re-connected to ESXi iSCSI.  I first tested on a unimportant LUN first.  All seemed well.  So I did this for all my StarWind devices.  Then following ESXi reboot problems.

Volumes not mounted.  Determined through some reading that ESXi was seeing them as snapshots.  If I mounted without re-signature then volume disappeared again at reboot.

So I went through the proceedure via SSH

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101138...

esxcfg-volume -l

esxcfg-volume -r VMFS_UUID|label

Completely removed all existing references to "old" volume names

Renamed all Volumes mounted as snap-*** to my original names

Re-registered all machines.

Finally volumes mounted following ESXi reboot.

This was a lot of unnecessary work that I don't want to repeat and would like to learn more of why it occurred.  Perhaps it's a question for StarWind folks...

What exactly changed with the ESXi "volume" Clearly I generated a new Starwind device but to an existing image file.  The actual VMFS volume inside that image file didn't change at all.  What is happening at the iSCSI level that this was seen as different to ESXi?

Thank you.

[MaxCraft · Accepted solution]

Hi,

When ESXi connects to the iSCSI LU it identifies it using multiple signs

1. Size

2. Vendor ID

3. Product ID

4. UUID

5. Serial ID

If any of the above doesn't match the original device you'll get into a situation you described in the original post.

I think this happened when you were re-adding the StarWind LU to the management console.

You have selected the img file and StarWind first threw a warning, saying that this is an existing device. If you chose to use the img file anyway, StarWind resignatured the device by generating a new UUID and Serial ID.

In future, please use the swdsk header when re-adding previously created devices to prevent UUID and serial ID change.

[SayNo2HyperV]

Thank you for feedback.

I tested this scenario with Starwind v8.  Creating target with disk.  Removing it.  Then creating new device with existing .img.

Now it is giving me the header warning prompt with option to use existing header or overwrite.  I did not get such a prompt when selecting my existing Starwindv6 created devices (.img files). 

V8 also gives the option when adding an existing disk to select the swdsk file rather than the .img.

Looks like I ran into this scenario as my devices were setup on Starwind v6.  I did not have swdsk files present where the .img file resides following the upgrade.  (Which is why I choose to remake the devices and re-attach existing .img file)

Your right.  Starwind did change the device/disk at this setup when it generated the new device with the swdsk format.

Take care .