9.3 iSCSI target problem for ESXi ?

[chiem]

My FreeNAS box supplies an iSCSI target that's used as a datastore for an ESXi box. On 9.2 everything was working fine, and I was able to reboot the ESXi box and the VMs auto-started fine.

After upgrading to 9.3, I have to go into vSphere Client after every reboot of the ESXi box and re-add the iSCSI target as a datastore. Anyone else run into this problem ?

 

[chiem]

This thread didn't get any responses after a couple of days, so I posted this same thread in the "9.3 Testing" forum and received a couple of responses: one from someone asking for more info, and another from someone saying they didn't have a similar problem with 9.3 and their ESXi setup. I didn't have time to look into the issue and respond further until now, and I can't find that thread anymore--it seems to have been deleted along with the "9.3 Testing" forum.

So.. now some more details:

I'm fairly new to iSCSI and ESXi, and started playing with it in 9.2.1.8. I was following a video tutorial, which I can't seem to find now, but it pretty much had me add a portal entry, initiator entry, and targets and extents, and associated them together using default values for the most part. The only thing I recall that wasn't quite default was having to enable a box under the first tab, per the video tutorial, which was probably "Enable LUC". I tested different VMs with datastores provided by NFS and iSCSI file and block extents. I also tested that the VMs came back up after rebooting the ESXi box. Everything was working fine..

Before I upgraded to 9.3, I whittled down to one iSCSI file-based extent/target and one VM to simplify things. I remember when I upgraded from 9.2 to 9.3, a couple of the entries in the iSCSI tabs were missing and had to be re-created. I don't recall exactly which tabs, but it was pretty much: click on "Add _____", accept defaults, click "OK" to replace the missing entries, and iSCSI on 9.3 was working again.

However, now whenever I reboot my ESXi box, the single VM on it doesn't start up and shows up as "Unknown". The datastore used by the VM (provided by that iSCSI target) needs to be re-added in vSphere Client under the host's Configuration tab > Hardware / Storage > Add Storage > Disk/LUN, where it spends a few seconds scanning for the target. Once that's done, the VM shows up and I can power it on again. How do I avoid having to do this with every reboot ?

I know the iSCSI service is provided by different software between 9.2 and 9.3. I can't find a corresponding "Enable LUC" option in 9.3, perhaps that has something to do with it ?

 

[cyberjock]

The 9.3 testing section was closed. As it was labeled at the top, it was scheduled to be removed after 9.3 was officially released. It was released, so that section was removed.

As for your problem, I don't know what to say. I know VMware treats iSCSI as a second class citizen, so I'm not surprised there are problems. But.... I'm using iSCSI for ESXi 5.1.0 build 2323236 and I'm having zero problems.

 

[chiem]

As for your problem, I don't know what to say. I know VMware treats iSCSI as a second class citizen, so I'm not surprised there are problems. But.... I'm using iSCSI for ESXi 5.1.0 build 2323236 and I'm having zero problems.

We have at least once difference.. I'm on ESXi 5.5.0 build 2068190.

 

[chiem]

Ok, digging a bit further on the ESXi side led me to this post:

https://communities.vmware.com/message/2400897#2400897

When re-adding the datastore back, I chose the "re-signature but keep data" option and this fixed the datastore mounting issue on reboot.

However, my single VM within that datastore was now listed as invalid/unavailable, so I had to add a new VM entry using the existing .vmdk file within the datastore. Everything was preserved within the VM except that the MAC address on the virtual NIC changed, so I had to update the my DHCP server. I also had to re-configure the VM to auto-start on boot.

Now everything is back to normal. I'm not sure what changed between 9.2 and 9.3 that required these steps, but it would have been nice if this could have been avoided.