VMware Cloud Community
SCPlus
Contributor
Contributor
Jump to solution

ESXi Delay First VM Autostart

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)?

SCPlus_0-1668716820103.png

 

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.

0 Kudos
1 Solution

Accepted Solutions
StephenMoll
Expert
Expert
Jump to solution

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

 

View solution in original post

61 Replies
virtualinca
Enthusiast
Enthusiast
Jump to solution

@SCPlus 

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 😉

Senior Engineer HCI@DellEMC | vExpert ️| VCP-DCV | vSAN Specialist | VxRail and VMware Data Center Virtualisation Implementor | VxRail and VMware Data Center Virtualisation Administrator | Owner of virtualinca.com |
0 Kudos
SCPlus
Contributor
Contributor
Jump to solution

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. 

0 Kudos
SCPlus
Contributor
Contributor
Jump to solution

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?

0 Kudos
SCPlus
Contributor
Contributor
Jump to solution

@virtualinca 

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?

0 Kudos
nsharpaus
Contributor
Contributor
Jump to solution

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.

0 Kudos
SCPlus
Contributor
Contributor
Jump to solution

The Dell Server I am using also has a BOSS.  Can you think of any way to delay the start of ESXi?

0 Kudos
nsharpaus
Contributor
Contributor
Jump to solution

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).

0 Kudos
nsharpaus
Contributor
Contributor
Jump to solution

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.

0 Kudos
scott28tt
VMware Employee
VMware Employee
Jump to solution

Create a "dummy" VM on a datastore which is available immediately, then have your regular VMs delayed from when the dummy VM starts?

 


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
0 Kudos
SCPlus
Contributor
Contributor
Jump to solution

Unfortunately, it does not seem that any datastores are ready fast enough for this to work.

0 Kudos
SCPlus
Contributor
Contributor
Jump to solution

Were you able to use autostart to delay the first VM after updating (and managing to get your missing datastores back!)?

0 Kudos
StephenMoll
Expert
Expert
Jump to solution

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.

 

 

0 Kudos
nsharpaus
Contributor
Contributor
Jump to solution

That's an interesting proposal -- I'll try it and report back.

0 Kudos
StephenMoll
Expert
Expert
Jump to solution

Good luck.

0 Kudos
nsharpaus
Contributor
Contributor
Jump to solution

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.

0 Kudos
StephenMoll
Expert
Expert
Jump to solution

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.

depping
Leadership
Leadership
Jump to solution

Probably won't work either, but you tried a boot delay in the VM itself?

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-EAAE9426-D08E-4DF...

0 Kudos
StephenMoll
Expert
Expert
Jump to solution

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. 

0 Kudos
SCPlus
Contributor
Contributor
Jump to solution

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.

0 Kudos