Posey's Tips & Tricks

How To Boot Hyper-V VMs in a Specific Order

From time to time, people will ask me if there is a way to ensure that Hyper-V virtual machines (VMs) can be automatically booted in a specific order. Unfortunately, Hyper-V does not contain such a mechanism, but there are some roundabout ways to control VM boot order.

One effective albeit somewhat haphazard technique involves setting the VMs' automatic start action. To access the automatic start action, open the Hyper-V Manager, right-click on the VM that you want to configure, then choose the Settings command from the shortcut menu. This will display the VM's settings.

The automatic start action is found near the bottom of the list of settings. You can see what this looks like in Figure 1.

[Click on image for larger view.] Figure 1: You can configure automatic start actions for each VM.

As you can see in the figure, you can configure the VM to start automatically, or to start automatically if it was running when the Hyper-V service was stopped. These options allow VMs to be brought back online if the Hyper-V server is rebooted.

If you need to control the VM boot order, however, then you can set the startup delay for each VM. For instance, you might set the startup delay for the first VM to 0, as is shown in Figure 1 above. You might then set the startup delay for the second VM to 60, so that Hyper-V waits for one minute before starting the VM. By adjusting the startup delay, you can effectively control the boot order.

If you need to exercise more stringent control over the boot process, guaranteeing that the VMs always boot in a specific order, then the best option may be to use PowerShell.

There is a PowerShell cmdlet named Start-Sleep that you can use to build delays into your script. For example, typing Start-Sleep 30 Seconds causes PowerShell to wait for 30 seconds before executing the next instruction in the script.

I have seen people create PowerShell scripts that start a series of VMs, with a Start-Sleep-induced delay occurring between each start action. Although this approach works, it is really no better than setting a startup delay within the Hyper-V Manager's automatic start actions.

A better solution is to create a script that actually checks to see if the previous VM has started before starting the next VM on the list. Believe it or not, this is actually relatively easy to do.

Suppose for a moment that I have a VM named DC and I want to make sure that the VM is running before I attempt to boot another VM. Here is what the script might look like:

Start-VM DC
$VM = Get-VM DC
While ($VM.State -eq 'Off'){
	Start-Sleep 10 Seconds

The first line in this script tells Hyper-V to start the VM named DC. The second line of code creates a variable named $VM and sets it equal to Get-VM DC.

The next thing that the script does is execute a while loop. The while loop works by checking if the VM's current state is equal to Off. If the VM is found to be off, then the loop uses the Start-Sleep cmdlet to wait for 10 seconds and then the loop checks the VM's state again. Once the state becomes something other than Off, the loop terminates and the script moves on to the next instruction.

In this case, there is no next instruction, but in a real-world environment this is where you would tell Hyper-V to start the next VM. You can repeat the code as many times as is necessary to boot all of the VMs.

Although the script shown above does work, there is one issue that I want to be sure to point out. When the script checks the VM's state, it only looks to see if the VM is running or not. It does not check to see if the VM's boot process is complete. For that, you would likely need to create a slightly more complex script that looks inside of the VM to see if the operating system is responsive. If there is sufficient interest, I might create such a script in a future column.

About the Author

Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.


comments powered by Disqus

Subscribe on YouTube