If you have Microsoft System Center 2012 R2 Update Rollup 7 or a later version in your Virtual Machine Manager (VMM) environment, you can now reassociate an orphaned virtual machine with its Service or VM role after the host server is recommissioned to VMM. This is helpful if Service or VM role VMs are orphaned during the host add or remove cycle. This is helpful also to implement Recovery and Backup scenarios for Services and VM roles.
What was the issue previously?
-
Sometimes, a host or a cluster can be decommissioned from VMM and must be restored. If such hosts or clusters had hosted virtual machines that were part of any Service or VM role, there was no option before UR7 for VMM administrators to reassociate the VMs to their respective Service or VM roles.
-
If Site Recovery Services are used when the primary site goes down, virtual machines are recovered at the secondary site. After the Service Templates became available at the secondary site, it was not possible previously to associate the recovered virtual machines to the newly deployed service instance.
How do I reassociate the virtual machine?
By using the following cmdlet, you can now reassociate the virtual machine to its Service or VM role.
Parameter Set: Service
Join-SCVirtualMachine [–VM] <VM> -ComputerTier <ComputerTier> [<CommonParameters>]
Parameter Set: VM Role
Join-SCVirtualMachine [–VM] <VM> -VMRole <CloudVMRole> [<CommonParameters>]This cmdlet runs a Re-associate task on VMM. This task performs a set of validations that help confirm the compatibility of the virtual machine with the service template. Click here to see the list of validation checks.
Parameter details
-VM <VM>
This parameter indicates the orphaned virtual machine that should be joined to a Service or VM role.
|
Aliases |
None |
|
Required? |
True |
|
Position? |
1 |
|
Default Value |
None |
|
Accept Pipeline Input? |
True (ByValue) |
|
Accept Wildcard Characters? |
False |
-ComputerTier <ComputerTier>
Use this parameter to specify the computer tier of a service instance to which the virtual machine should be joined.
|
Aliases |
None |
|
Required? |
True |
|
Position? |
Named |
|
Default Value |
None |
|
Accept Pipeline Input? |
False |
|
Accept Wildcard Characters? |
False |
-VMRole <CloudVMRole>
Use this parameter to specify the VM role to which the virtual machine should be joined.
|
Aliases |
None |
|
Required? |
True |
|
Position? |
Named |
|
Default Value |
None |
|
Accept Pipeline Input? |
False |
|
Accept Wildcard Characters? |
False |
Examples
Example 1: Joining an orphaned virtual machine to a service tier
$vm = Get-SCVirtualMachine –Name "PS-Web-001"
$ct = Get-SCComputerTier –Name "MyService-WebTier"
Join-SCVirtualMachine –VM $vm –ComputerTier $ct
Example 2: Joining an orphaned virtual machine to a VMRole
$vm = Get-SCVirtualMachine –Name "PS-Web-001"
$vmRole = Get-CloudResource –Name "PetShop"
Join-SCVirtualMachine –VM $vm –VMRole $vmRole
Screen shots
The following screen shot shows the behavior of VMM before this functionality was introduced. The Services pane in VMM shows that the virtual machines for the service instance are missing.
The following screen shot shows the behavior after the virtual machines are reassociated to the service instance.
Assumptions made before you reassociate the virtual machine
-
It is assumed that the virtual machine is running, and that all the guest applications and services that are running on it are intact.
-
The computer tier to which the virtual machine is being joined must run at less than its maximum instance count. The upgrade domain for the join operation resembles a scale-out.
-
The virtual machine that is reassociated must be the one that was originally part of a Service or VM role deployment. Also, it must not be changed in such a manner that it fails the VMM validation check. (See the "List of validation checks" section for a full list of checks).
A word of caution
The process of joining a virtual machine to a Service or VM role that uses load balancers is not supported. If you try to join a virtual machine to such a Service or VM role, the user must configure any load balancer settings manually.
List of validation checks
The following is the list of validation checks that are performed to verify compatibility of the virtual machine with the service template.
Virtual machine and ComputerTier status
The virtual machine has to be in a running state, and the computer tier has to be in a deployed state. Also, because this operation resembles a scale-out, the total number of virtual machines for the tier should not exceed its maximum limit.
-
Check whether the virtual machine is in a running state.
-
Check whether the virtual machine is already associated to a computer tier.
-
Check whether the computer tier is in Deployed state.
-
Check whether the VMInstanceCount value of the tier is less than the maximum.
Verifying virtual machine scope
A service can be deployed on a Cloud or a HostGroup. The virtual machine should be in scope of the Cloud or HostGroup in which the service is deployed.
-
Check whether the virtual machine is in the scope of the service instance.
-
Check whether the owner of the virtual machine is the same as the owner of the service instance.
-
Check whether the UserRole of the virtual machine is the same as that of the service instance.
Networking checks
Basic minimal checks are performed on the virtual machine networks and IP address types that are expected on a virtual machine.
-
If there is a virtual network adapter (Virtual Network Interface Card, or vNIC) on the virtual machine that matched the virtual machine network, check for every network adapter that is defined by the template.
-
Check IP Address types.
Verifying guest agent state
If the virtual machine template of the computer tier requires the guest agent to be present on the virtual machine, the following checks are performed:
-
Verify that there is a guest agent installed on the virtual machine.
-
Check whether the guest agent is responding (heartbeat).
-
Verify the guest agent version.
Note If a computer tier has one or more LBVips (Load Balancer VIPs) associated with it, and the tier machine instance count is zero (0), this cmdlet cannot be used to associate a virtual machine to such a tier.
That is, for a computer tier having LBVips, the virtual machine that is being associated cannot be the first virtual machine of the tier. It must have at least one existing virtual machine that can be obtained by scaling out that tier. In this situation, we recommend that you scale-out the tier to have at least one virtual machine. You do this to avoid issues that affect NLB clusters in which the tier might not have any NLB node and we try to add a VIP member that eventually fails.
