How to manage VM pinning within a Hyper-V cluster by combining the use of System Center VMM and Orchestrator

Article
1/17/2024

Introduction

Hyper-V clusters allow improving the efficiency of computing resources and VMs availability. A good balancing for the load of VMs on Hypervisors in a Hyper-V cluster is one of the challenges for Virtualization administrators and having it properly managed allows avoiding and minimizing slow performance of VMs and crashes of Hypervisors.
This Wiki article shows a way to combine the use of System Center VMM and Orchestrator in order to manage the VM pinning to Hypervisors.

How to combine the use of System Center VMM and Orchestrator to manage VM pinning

To combine using System Center VMM and Orchestrator to manage VM pinning, all you need are:

An SQL table that has the following columns:
- Host: This column is used to store the VM name
- Hypervisor: This column is used to store the name of the Hypervisor that the VM should be pinned to
- Automation: This column is used to specify if a VM pinning is managed by Orchestrator or not

Orchestrator Runbooks to import your servers from SCVMM to the SQL table
Orchestrator Runbooks to process VM pinning

Orchestrator will rely on the data stored in the SQL table to process the VM pinning. It will identify the Hypervisors on which the VMs are running and initiate a Live Migration (If possible) in case if a VM is not running on the Hypervisor where it should reside. Moving a VM from a Hyper-V Host to another will be done by using the available SCVMM activities.

Below is an example to allow a better understanding about how Orchestrator will process the VM pinning.

Let’s suppose that we have a Hyper-V cluster that is composed two (2) Hyper-V servers where four (4) VMs are running.

The next table shows the Host, Hypervisor and Automation values stored in the SQL tables:

Host	Hypervisor	Automation
VM1	Host1	1
VM2	Host1	1
VM3	Host2	1
VM4	Host2	NULL

Remark: When Automation value is equal to 1 for a VM then the pinning via Orchestrator is enabled.

Orchestrator will read the data from the SQL table and will identify the VMs that are in its scope.

Host	Hypervisor	Automation
VM1	Host1	1
VM2	Host1	1
VM3	Host2	1

Orchestrator will then check that the VMs are running on the correct Hypervisor and will move them if this is not true.

Configuration of Orchestrator

Import of VM servers list from SCVMM to the SQL table

You will need to have two Runbooks to import the VM servers list from SCVMM to the SQL table:

A Runbook to get the list of VM servers from SCVMM and invoke the second Runbook
A Runbook to store a VM name in the SQL table if it does not exist

Let’s start with the second Runbook. You will need to use three (3) activities:

Initialize Data: It will allow the Runbook to take the VM name and its current Hypervisor as input

Query Database: It will take the VM name provided by Initialize Data activity to check if it already exists in the SQL table or not.

Write To Database: It will create a new entry for the VM name if it does not already exist and will register its current Hypervisor name

The link between Query Database and Write to Database activities need to be set with the following include condition: Number of rows from Query Database equals 0. This allows adding a new row for the VM name only if it does not already exist.

Below is a screen capture of all the activities included in the second Runbook:

Once you have created the second Runbook, you can proceed with the creation of the first one. You will need to use four (4) activities:

Monitor Data/Time: It will allow you to specify the time of when the Runbook need to start running

Check Schedule: It allow you to specify the slot of days and hours when the Runbook can start running (By combining the settings in the activity and the ones from the previous activity, you will be able to precise the dates and times of when your runbook can start running)

Get VM: It will allow you to get the VM servers list from SCVMM

Invoke Runbook: It will allow you to run the second Runbook and to provide the VM name and its current Hypervisor for every VM in SCVMM as input.

Below is a screen capture of all the activities included in the first Runbook:

Processing of VM pinning

You will need to have two Runbooks to process VM pinning:

A Runbook to get the list of VMs and invoke the second Runbook
A Runbook to check if a VM is running on the correct Hypervisor. If this not the case, the Runbook will initiate a move of the VM to the correct Hypervisor.

Let’s start with the second Runbook. You will need to use four (4) activities:

Initialize Data: It will allow the Runbook to take the VM name as input

Query Database: It will take the VM name provided by Initialize Data activity and will retrieve the name of the Hypervisor on which it should reside

Get VM: It will query SCVMM to check if the current Hypervisor of a VM is the Hypervisor where it should reside or not.

Move VM: It will move a VM from its current Hypervisor to the Hypervisor where it should reside.

The link between Get VM and Move VM activities need to be set with the following include condition: Number of Objects from Get VM does not equal 0. This allows initiating the move of a VM only if it is not running on the correct Hypervisor.

Below is a screen capture of all the activities included in the second Runbook:

Once you have created the second Runbook, you can proceed with the creation of the first one. You will need to use four (4) activities:

Monitor Data/Time: It will allow you to specify the time of when the Runbook need to start running

Check Schedule: It allow you to specify the slot of days and hours when the Runbook can start running (By combining the settings in the activity and the ones from the previous activity, you will be able to precise the dates and times of when your runbook can start running)

Query Database: It allows getting the list of VMs in the scope of Orchestrator for the VM pinning (These are the VMs having 1 as the value for Automation column)

Invoke Runbook: It will allow you to run the second Runbook and to provide the VM name for every VM in the scope of Orchestrator VM pinning as input.

Conclusion

This Wiki article shares a way to VM pinning by combining the use of System Center VMM and Orchestrator. The proposed method is suitable VMs running in on a Hyper-V cluster. The provided Runbooks can be customized to meet your company requirements. Once implemented, all you need to manage will be the Hypervisor and Automation variables for your VMs by updating the SQL table.

Share via