Booting Hyper-V VMs in a required order: Put yourself at ease!

INTRODUCTION

Virtualization of your work servers is a necessary action, but the problem is when you do that, you basically put all your eggs in one basket. Let’s imagine that your Hyper-V host with several VMs on it requires rebooting. Well, in that case, you won’t be able to boot a specific VM until the host OS is restarted, and all VMs are booted. And there’s no guarantee they will be available after that! Now, that surely doesn’t sound too good. However, luckily there are ways to make this process less painful and more efficient.

While configuring Hyper-V host, you’ll have to be able to boot your VMs in a specific order. I gotta admit, even though it took me a while to figure out how to customize this process, I have some results for you.
Mind, even if your server OS isn’t prone to failure, it’ll still be wise to configure Hyper-V automatic start action for VMs. One way or another, someday, you’ll have to reboot your server. So, when such a reboot occurs, it would’ve been nice if you didn’t have to boot ever separate VM manually, don’t you think so?

REASONS FOR CONFIGURING AND OPTIMIZING VM BOOTING ORDER

Memory leak

Even though in the latest version of its OSs and Hyper-V supervisor Microsoft has dramatically improved memory management for every VM, it’s still quite a pickle to get rid of memory leaks completely. Sometimes, upon starting, it can distribute to a specific VM more memory than it was configured in the settings. That’s why it’s better to boot VMs in a particular order.

Processor resources

The same thing goes for allocating processor resources to each specific VM. Start them up all at once, and your hypervisor is frozen (server, perhaps, too). So, just line them up in a specific order and enjoy a smooth ride.

HDD access

While using HDD disks, even in RAID, I personally had encountered situations when the VMs were reading data from different parts of RAID massive simultaneously. Not only that but also the booted VMs were acting out. So, the main advice is that you better should move your VM images to SDD and allocate them in order.

Power supply module

According to my calculations, when you start the 1200W server, it can give away x2 of power supply, tops. Not so hard to tell, it can overload the uninterruptible power system of your server quite easily. Simple solution? Yep, you guessed it right: booting your VMs in a specific order. However, do keep in mind that this simple trick is only useful when you have either tons of VMs or your VMs consume all available power when all booted in one time.

Setting the startup delay into the sequence helps you to make sure that only one virtual server is booting at once. Also, you’ll be able to tell if your VMs are booted in a requested order. For example, say, you have an application server and domain controller/DNS server. In that case, you need to make sure that the domain controller and DNS services are a go BEFORE you boot the application server. If you set a delay for the application server, you have this one covered.

IT’S CONFIGURATION TIME!

First of all, it’s necessary to mention that Hyper-V doesn’t contain a mechanism to boot VMs automatically in a specific order, but sometimes, you need to cut the corner.

As the first step, open the Hyper-V Manager, right-click on the VM that you want to choose, then select the Settings command from the shortcut menu. Now, you can see the VM’s settings.

Second, the automatic start action is disposed near at the end of the list of settings. You can check it out in Picture 1.

As you can see in Picture 2, the VM can be configured to start automatically. Or, to start automatically in case it was running when the Hyper-V service was stopped. These choices let VMs to be brought back online if the Hyper-V server is rebooted.

With these settings, you can set the startup delay for each VM. In fact, for example, you might wanna set the startup delay for the first VM to 0, as is shown in Picture 3.

Furthermore, as the next step, you are able to set the startup delay for the second VM to, say, 60, as in Picture 4. Now, Hyper-V waits for one minute before starting the VM. The point is, adjusting the startup delay enables you with the means to control the boot order effectively.

WHAT IF…

… I want my VMs to always boot in a required order?

Well, then, the best you can do is PowerShell!

Among dozens of PowerShell cmdlets, there is one called Start-Sleep. You are welcome to use it to build delays in your script. For instance, if you type Start-Sleep 30 Seconds, PowerShell is going to wait for 30 seconds before executing the next instruction in the text of the script. Quite a simple and rewarding example.

There is also a possibility to create numerous PowerShell scripts for starting a series of VMs (a Start-Sleep-induced delay takes place between each start action). Naturally, this works, but I really can’t see any difference from just setting a startup delay within the Hyper-V Manager automatic start actions.

The best choice is writing a script to actually check if the previous VM has started before starting the next VM on the list. It ain’t half as hard as it sounds.

Let’s say I have a VM named TEST1, and I’m eager to make sure that the VM is running before I boot the next VM. The script will be looking something like that:

The first line commands Hyper-V to start the VM named TEST1.

The second one creates a variable named $VM and sets it as equal to Get-VM TEST1.

The next step in scripts orders is to execute a loop. This loop is set to check whether the VM current state is equal to Off. In case the VM is actually off, the loop waits for 10 seconds with the Start-Sleep cmdlet, and only then rechecks the VM state. When it changes to something different than Off, the loop terminates, and the script moves on to the next step.

Of course, in our case, the next step is nothing, but in your working environment, you can easily use it to start the next VM. Just repeat the code the exact amount of times you need to boot all of the VMs.

CONCLUSIONS

The script is also quite simple in use. To employ it properly, just start the server and enter the script. Or, better so, introduce the script to the task manager. it would be best to keep it at hand if you won’t be able to spend time on applying it manually, or, better so, if another admin will have to get to work. This script, undoubtedly, is entirely efficient in what it does, but there’s still something you need to know right away. The script is checking VM state to see if it is running or not, and that’s all. Sadly, it won’t be able to tell if the booting is completed. If you want that, well, you ought to develop a bit more complicated script, to be able to look at what’s going on inside the VM. Now, that script will tell you whether the processes are active and responsive or not.

But that’s a whole other story.

In case you want more details about how this all works, I suggest you check Microsoft’s official documentation on Hyper-V and PowerShell.