Automounting Datastore (iSCSI target on same ESXi host)

[AndroidCat]

Scenario:
-iSCSI Target is provided by a VM
-then mounted as a host's Datastore
-ESXi gets rebooted and because target is not present during ESXi start-up (as that VM has not even booted yet) the iSCSI Datastore never gets mounted

/*I know the set-up is less than ideal, but for home environment must do for now. iSCSI datastore is for testing and less critical stuff. Main Datastore is local NVME*/

Surely in that scenario the system behavior is as expected, but not desired. Manual re-scanning and re-mounting is not feasible.
iSCSI Advanced Parameters tuning (timeouts, retries) are useless IMHO. Done some testing on that.

The solution which works for me is to send
esxcli storage core adapter rescan --all

from iSCSI Target VM (when this fully boots) to ESXi host. Then Datastore gets re-mounted and everybody's happy.

Any of you using similar setup having any tricks to re-mount iSCSI datastore?

 

[realtomatoes]

i went with nfs on freenas vm. nfs gets mounted auto-magically as soon as the freenas vm is operational. all i had to do was add the freenas to the auto-start vm list.

if you wanna stick with iscsi, you can setup another vm that will run a script to recan the esxi storage. set a delay to boot your start up vms to make sure the storage vm boots first and then other vm with the script to scan.

 

[Cadal]

I know this thread is a bit old but thought this would be of interest... I too went with nfs (3) however Spearfoot on freenas forums has some nice scripts to perform the rescans for iscsi and other scripts for AIO builds. I was just using corral till it got 'canned' so have been setting up ESXi 6.5 / FreeNas 9.10.2 AIO.

 

[browned]

In the etc/rc.local.d/local.sh script (like autoexec for DOS) you can add commands, This is what we do at work for our HP VSA Machines.

#!/bin/sh

# local configuration options

# Note: modify at your own risk! If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading. Changes are not supported unless under direction of
# VMware support.

# Start the VM Server that provides the iSCSI LUN, change VMSERVERNAME.
vim-cmd vmsvc/getallvms | grep VMSERVERNAME.vmx | cut -d ' ' -f 1 | xargs vim-cmd vmsvc/power.on

#Wait
sleep 180

#Enable iSCSI Initiator and rescan for iSCSI LUNs.
esxcfg-swiscsi -e
esxcfg-swiscsi -s

exit 0


HP Also has an iSCSI rescan tool Index of /sdr/repo/vibsdepot/hpq/HP-StoreVirtual not sure if this rescans for all iSCSI LUN's or just HP Lefthand LUNs.

 

[nk215]

Is the main benefit of this type of AIO is redundancy protection for datastore? In my AIO, I just use local SSD for datastore/VM. Data within the VM are store on a NAS VM.

 

[browned]

Don't think this is for AIO if I understand that correctly. HP VSA and VMWare VSAN require two or more hosts, the storage is mirrored between them so if a host fails or has an issue the VM's can be migrated to the other host and there is no down time while the faulty host is repaired.

 

[darklight]

That's exactly the situation I had on my vSphere cluster where Starwinds is used to provide iSCSI-based datastores for the cluster. They have a nice guide on how to configure an automatic storage rescan as soon as the storage virtual machine is up and running: StarWind Virtual SAN Hyper-Converged 2 nodes scenario with VMware vSphere. It's on page 17.