Hi there,
I am running ESXi 7.0 update 3 on a Dell server. Autostart is enabled under Host > Manage > Autostart (see settings in screenshot below). The issue is that as soon as ESXI powers on, it attempts to start the VM. However, the disk is not yet available so it throws the error "Failed - The attempted operation cannot be performed in the current state (Powered off)."
How can I delay the start of this VM until the disk starts and the VM is available? Why will it not wait for the start delay I have set (300 sec)?
Thank you in advance!
Edit to add solution:
Thank you @StephenMoll for the help! Using @StephenMoll's code (marked as the answer) I was able to delay EXSI from trying to autostart until the datastore was available. Having the script running in local.sh stops ESXI from initiating its autostart until after rc.local has completed. I did not even have to start the VMs in the script - it is still done by ESXI autostart.
As mentioned in another comment, the code needs to be placed in etc/rc.local.d/local.sh
local.sh only runs when UEFI Secure Boot is Disabled in the BIOS.
I developed a script for one of our systems that checks for datastore access, and stays in a loop until the datastore is contactable.
We had to do this because the way the system was powered up, was via a big single switch. The hosts would boot up quicker than the SAN, resulting in hosts booting without datastores being connected.
The script did much more than that but it has a snippet much like this, which will make up to 5 attempts, a minute apart to see a chosen datastore:
DefaultDS="{Put_datastore_name_here}"
logger -s "Checking for $DefaultDS"
for ATTEMPT in 1 2 3 4 5
do
if [ ! -L "/vmfs/volumes/$DefaultDS" ]
then
logger -s "$DefaultDS not accessible - HBA Rescan triggered"
sleep 60s
esxcli storage core adapter rescan --all --type=all
else
logger -s "$DefaultDS accessible"
break
fi
done
Start Delay – After you start the ESXi host, it starts powering on the virtual machines that are configured for autostart. After the ESXi host powers on the first virtual machine, the host waits for the specified delay time and then powers on the next virtual machine. The virtual machines are powered on in the startup order specified in the Per-VM Overrides pane.
What you configured is the maximum time to wait before powering on another.
If this was helpful, don't forget kudos 😉
So really Auto Start Delay applies to the VM that is starting after the VM where that is set?
How can I delay the start of the first (and only) VM then? It is trying to boot before the data stores become available.
This is still unresolved. How can I delay that VM from starting until the disks are available? Is there a way to get ESXI to continually try to start the machine if it is not running?
I responded before but did not @ you.
Anyway, this is still unresolved. I need to delay the start of the first machine until the disks have spun up and the VM is available.
Any other ideas?
I have seen something very similar in a Dell server I am working with. The new BOSS card requirements in ESXi 7 may be causing a race condition between the OS being available and the datastore not yet being available. So, auto-starting any of my VMs fails with the same error. We never had this issue previously when running ESXi from an SD card/USB drive.
The Dell Server I am using also has a BOSS. Can you think of any way to delay the start of ESXi?
I have not found a way to do this (it was my first thought as well). The Autostart start delay configuration only affects the timing between multiple VMs that are auto-started. And, in my case, ESXi 7 tries to start all 5 of my VMs within a 4-second window (all fail to start).
Just as a side note: I tried updating to ESXi 7.0.3 Update 3g, as I saw many references to datastore issues that were fixed in Update 3f.
Long story, short: my datastore now no longer exists. Glad this isn't yet a production server! I went to Storage -> Devices -> Rescan, and now my datastore shows up again.
I am thoroughly unimpressed with the stability of ESXi 7.
Create a "dummy" VM on a datastore which is available immediately, then have your regular VMs delayed from when the dummy VM starts?
Unfortunately, it does not seem that any datastores are ready fast enough for this to work.
Were you able to use autostart to delay the first VM after updating (and managing to get your missing datastores back!)?
Dummy VM doesn't even need a disk, and therefore would not be subject to the same problem.
Start "Create VM" wizard, select OS other 32bit, delete "Hard disk 1", set cores to 1, memory to 64MB (Wastes less if left running).
There you have it, a VM about as resource frugal as possible and no storage required.
That's an interesting proposal -- I'll try it and report back.
Good luck.
No, there seems to be no way (I can see, at least) to delay the start of the first VM.
I think I would have to define the "dummy VM" into a datastore on the same BOSS card -- which may not be possible (not sure).
Even if there is no hard disk attached to the "dummy VM", it still requires a configuration file (.vmx) that has to reside on a datastore somewhere. This is actually what seems to fail in my case -- the configuration file cannot be read from the datastore to start loading the VM.
Yup. I would say that sounds about right. The point of creating a VM without a vDisk is that it will not be writing to wherever the Vm gets created, and the VMX file is rarely written too. BOSS cards have good write longevity anyway.
Once the dummy VM has started, you can set the delay to the next VM in the sequence to whatever delay you need.
The only other approach I can think of, would be to try and use the local.sh script file to create a delay in the host bootup sequence. This may not work though as using it becomes more difficult, especially if using TPM.
Probably won't work either, but you tried a boot delay in the VM itself?
Its a good idea Duncan, but my interpretation is that the OP needs a VM that can start without the proper datastores being fully available.
So even the VMX file of the 'Dummy VM' needs to be accessible before the storage comes fully online.
Therefore the method you propose would not be useful by itself, because none of the proper VMs can start at the time 'autostart' attempts to power them on. So for his purposes it doesn't matter if the delay occurs before or after the first VM anyway. The crucial thing is the second VM only attempts to start after a delay long enough to be sure the datastore is ready to be used.
You are correct. Because the datastore was not available for the "dummy VM", it failed to start. Then it skipped the delay and tried to start the VM I actually want. It, of course, failed because the datastore was not available.