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 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:
|

|
|
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:
Let’s start with the second Runbook. You will
need to use three (3) activities:
|

|
|

|
|

|
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:
|

|
|

|
|

|
|

|
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:
|

|
|

|
|

|
|

|
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:
|

|
|

|
|

|
|

|
Conclusion
|
This 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.
|