Obviously if your filer is a VM on your ESXi box your datastore won’t be available until that box is fully booted, this is rather irritating as generally one wants at least some of the VMs on a given host (aside from the filer) to boot when the host boots, fortunately this is not too hard to fix.

Important note (trap for young players, and something I derped on for a couple of days the first time round…) there’s a global setting to enable autostart, Manage->System->Autostart->Edit Settings->Enabled->Yes, probably also want to set “Stop Action” to “Shutdown” and enable “Wait for heartbeat” while you’re there. And then setup your autostart order (obviously the filer needs to be the first VM in the autostart order).

Basically, we want to tell the ESXi box to rescan its devices and datastores after your filer is properly booted, and the easiest way to do this (I tried various other jiggery-pokery first without success) is to run a script on your filer after it has finished booting. Back in the day you’d use /etc/rc.local (and you still can on anything built on SysV Init), but because Alpine is using OpenRC things are a bit different here (if you are using a SystemD based distro, ask google for “SystemD rc.local” and you’ll find instructions for how to replicate the functionality of rc.local in that ecosystem).

In order to do that you’ll need to enable the SSH service on ESXi (Manage->Services->TSM-SSH set Policy to “start and stop with host”, start the service), and configure SSH key-based authentication (ask google if you don’t know how). One important point here is that ESXi doesn’t store authorized_keys in the “traditional” location, instead you need to populate them at /etc/ssh/keys-<username>/authorized_keys, but other than that it’s the same as any other box.

Now we turn our attention to our filer, first we need to enable “local”;

alpinefiler# rc-update add local 
 * service local added to runlevel default

Next we create a “start” script under /etc/local.d, mine is called “ESXiSystemUp.start” (make sure it’s marked executable, 0700 permissions will do nicely) and the contents are as follows;

#!/bin/sh
scp -i <path_to_private_key> /<path_to>/systemup.sh root@<esxi box>:/
ssh -i <path_to_private_key> root@<esxi box> /bin/sh /systemup.sh

Note that I’m copying the script up from the filer before executing it, it is possible to create persistent storage outside of datastores on an ESXi box (you could also do it via oem.tgz, and I suppose in that case you could just run it out of cron) but after briefly looking at the procedure I filed it under “too much effort” and went with the above instead.

The contents of the “systemup.sh” script are below.

#!/bin/sh

DS_NAME=<YOUR DATASTORE>

rescan_storage() {
    esxcli storage core adapter rescan --adapter=vmhba64
    vmkfstools -V
}

wait_for_datastore() {
    echo "Waiting for datastore"
    rescan_storage
    while [ ! -e /vmfs/volumes/$DS_NAME ]
    do
        echo "Datastore not ready, retrying in 30 seconds"
        sleep 30
        rescan_storage
    done
}

wait_for_datastore
echo "Datastore found, continuing autostart"
vim-cmd hostsvc/autostartmanager/autostart

The script is pretty straight forward, it basically just does an adapter rescan followed by a datastore rescan, checks if the datastore has appeared, if not it waits 30 seconds and repeats, once the datastore becomes available we make a call to vim-cmd to re-initiate autostart which will pick up from whereever you were up to in the autostart order.

And you’re done.