Introduction
Since I couldn’t find any good documentation about the ‘Add-SCVMHostCluster’ cmdlet from Microsoft or any other source, I decided to do a blog about it and hopefully save some people from allot of frustration.
In my case, I had an existing cluster with six hosts managed with VMM SP1. This VMM instance is fully configured with ‘Network Sites’, ‘VMnetworks’, ‘Virtual Switches’ on the hosts and ‘Logical Switches. Beside this cluster I also have a new cluster managed with a newly build VMMR2 instance. My goal is to decommission the existing cluster and migrate all the VM’s without any downtime to the new R2 cluster. The only solution at hand is using ‘Storage Live Migration’, this required me to add the existing cluster to the new VMMR2 instance so I could leverage the ‘Move-SCVirtualMachine highlyAvailable’ command which initiates the VM migration.
You are able to add the cluster via the VMM console but of course everything is executed with PowerShell, the console uses the cmdlet ‘Add-SCVMHostCluster’ for that. In most cases you want to implement the changes in production and therefore have a change process in place which requires you to know exactly what kind of impact can be expected by executing certain commands. And since there is no exact documentation what this cmdlet does I had to find it out for myself. After searching google, I read cases with VMM versions prior to R2 where hosts would just reboot without any warning. Mostly because of pending restarts or pending restarts caused by the installation of a new VMM agent on the host, this was also acknowledged by a SystemCenter expert. So I had to make sure there were no pending reboots and used this cool script to check all the hosts, luckily there were no pending reboots found. What I also found out was that the cmdlet also recreates the ‘Logical Networks’, but for this to happen you have to set the ‘Automatic creation of Logical Networks’ in VM.
“Set-SCVMMServer -AutomaticLogicalNetworkCreationEnabled $true“
The cmdlet description talks about adding a whole cluster to VMM but a cluster consists of multiple hosts and you don’t want to change each host and affect all your VM’s on the cluster with possible outage caused by a restart or changes in the network topology. I used the wizard in the VMM console to generate the script and in one of the steps it warns you about the following:
“If the Hyper-V role is not enabled on any of the selected servers, Virtual Machine Manager will enable the role on those servers as part of the Add Host process, which will result in a restart of the servers. If any of these servers have a pending restart, they will also be restarted”
So you could interpret this two ways, it would restart the server if it has a pending restart or it can cause a pending restart with an installation process and restarts the server. Pretty vague and strange, there is no documentation to clarify this command which could have a very high impact on your environment.
Executing Add-SCVMHostCluster
At the end of the wizard I viewed the script and this is what I’m going to execute, I left the host group and account credentials out.
Add-SCVMHostCluster -Name “existingcluster” -RunAsynchronously -VMHostGroup $hostGroup -Reassociate $true -Credential $runAsAccount -RemoteConnectEnabled $true
As you can see the ‘reassociate’ parameter equals true, it means that I have an existing cluster managed by another version of VMM and I want to associate the cluster to my new VMM instance. In my understanding this could mean that it would do something with the existing VMM agent, update the configuration or the agent itself with a new version which also could trigger a reboot. Before executing the cmdlet in production I strongly advise to test this in a properly setup staging or poc environment with the same versions running in production. Now let’s execute the cmdlet and see what happens.
It first creates the cluster administrative entry in VMM and adds all hosts to it, then it creates a new job for every host and tries to associate the host with VMM by installing the agent and update the configuration. Meanwhile you will see the cluster in VMM and all hosts under that container/folder along with a pending status until the job for adding the host succeeds and VMM can manage that host. In my case all jobs failed because there is an existing VMM agent present. Luckily it did not uninstall the agent automatically (and reboot), but now advises to uninstall the agent and retry the operation again.
“Error (408) ‘host’ has an unsupported version of the Virtual Machine Manager agent installed. Uninstall the Virtual Machine Manager agent using Add or Remove Programs on ‘host’, and then try the operation again.”
The separate jobs allows you to safely move all VM’s from a host and uninstall the agent, reboot if necessary and retry the job. And repeat these steps for every host without the risk of real downtime. After you completed the tasks above and retried the job it should complete with the following job report.
Analysis
The job installed the VMM agent and refreshed the host. Apparently VMM doesn’t know about any VMM configuration which was applied in the old VMM environment. To understand how VMM picks up the networking already present on the host and the VM’s you need to know that the extra network configuration done in the old VMM can only be seen as administrative management information on top of the real configuration itself which lives on the Hyper-V host. It can purely seen as an extra layer to effectively manage group of hosts and clusters. The network configuration from VMM is applied on the host itself, in the cluster role or the corresponding xml file where the VM configuration lives. So when VMM executed the ‘Add Host’ job and the agent is installed it is able to communicate with the newly added host. The host will be refreshed and along with this refresh it reads out the ‘virtual switches’ and VM’s on that host and creates the network configuration based on that, it doesn’t know about the previous configuration from the old VMM instance. For each ‘virtual switch’ on the host it will create a so called ‘one connected’ ‘logical network’ with a ‘VM network’ attached to it, both names match the virtual switch name. This ‘logical network’ is directly attached to the ‘virtual switch’ on that host. Configuration on the hosts will remain untouched.
You may have to manually refresh the host and the virtual machines on that host. If there are VM’s which have an “Unsupported Cluster Configuration” status it’s because they are not refreshed correctly or there is something with the network configuration. Try to refresh the VM’s individually by multiple select the VM’s, right click and refresh them.
If you open up the VM network adapter configuration you will see that the switch is replaced from a logical switch to a standard switch, this standard switch is actually mapped to the virtual switch on the host. Some VM’s have only the VLAN id set and some the VLAN id and the VM network which corresponds to the switch.
Conclusion
I hope I somewhat clarified the workings of this cmdlet, in my case the next step was storage live migrating the VM’s to the new cluster and select the new ‘VM Network’ on the new cluster for each of them. If you don’t want to decommission the old cluster and retain all configuration then I would highly recommend to import or upgrade the original VMM database.
