In my previous post, I talked about how we can use CheckSystemCompatibilityInfo() and GetSystemCompatibilityInfo() methods to check host compatibility checks before performing quick or live migrations. I had mentioned that I will post a script around these methods. In this post, I will release – download at the end of post — the script and talk a bit about how the above mentioned methods are used.
Here is the usage of this script
cscript getcompatibility.vbs /SRCHOST:[HOSTNAME] /DESTHOST:[HOSTNAME] /VMNAME:[VM_NAME]
In the above command-line,
SRCHOST is the name of the Hyper-V host from which you want to migrate the virtual machines
DESTHOST is the name of the Hyper-V host to which you want to migrate the virtual machines
VMNAME is the name of the virtual machine — running on SRCHOST – you want to migrate
In this parameters, SRCHOST and DESTHOST parameters are mandatory and VMNAME is optional. If you refer to the GetSystemCompatibilityInfo(), the ComputerSystem input parameter can either be a Hyper-V host name or a virtual Machine element name. If the input is a Hyper-V host, this script will specify if you can move any of the virtual machines hosted on the SRCHOST to DESTHOST. If the parameter is a virtual machine element name, the output will mention if the VM can be moved to DESTHOST or not.
cscript getcompatibility.vbs /SRCHOST:server1 /DESTHOST:Server4
cscript getcompatibility.vbs /SRCHOST:server1 /DESTHOST:Server4 /VMNAME:VM1
This script will verify if Hyper-V WMI interfaces are available on SRCHOST and DESTHOST. If the virtualization namespace is not available on the given hosts, script will exit with an error message. However, when a VM cannot be migrated to DESTHOST because of compatibility issues, this script will just output the XML content of Msvm_Error instance. I am still working on getting useful information out of the XML data and provide it as output.
You can run this script from any system that has support for running a VBScript and WMI.
Give an option for a text file input containing server names
Release PowerShell version of this
Integrate with a few fail-over cluster Cmdlets to make updates to “preferred node” for migration based on compatibility
Integrate with migration cmdlets to trigger the migration itself
I will post all updates over here. Keep watching this space
[download id=”9″ format=”4″]