Published: Nov 27, 2013
Welcome to this series on System Center Virtual Machine Manager 2012 R2! In part one, I discussed upgrading to System Center Virtual Machine Manager 2012 R2 (SCVMM 2012 R2). In part two, I provided an overview of migrating to SCVMM. Now that you have an overview of the process of migrating our SCVMM environment to 2012 R2, let’s take a deeper dive into the steps we’ll be taking to migrate the hosts and library.
In this post we will focus on both the Hyper-V hosts and the logical networks we will be hosting, in addition to the addition of our library servers. What I will not be covering here is the procedure to create a logical switch, as depending on your environment you might for some obscure reason wish to use the old virtual switch format. The samples I will present are based on the assumption that you are migrating from a virtual switch, leaving you the option to start initial with a virtual switch and upgrade to a logical switch when suitable.
Keep in mind that as we cover each step, we are moving steps away from a quick rollback option. However, assuming you keep note of where you are, reversing these changes (should that be necessary) should be a quite similar exercise.
We can now change to the Fabric view in VMM, as next we will create a host group for the Hyper-V hosts that will be used to organize the servers and clusters which host our compute fabric. An example of the simple hierarchy I require to implement is to create a parent group called Operations, which has two children, namely WS08R2 and WS2012. The PowerShell to implement this is as follows.
New-SCVMHostGroup -Name Operations New-SCVMHostGroup -Name WS08R2 -ParentHostGroup Operations New-SCVMHostGroup -Name WS2012 -ParentHostGroup Operations
We can now begin to add our Hyper-V hosts to VMM for management. If these hosts have a VMM agent deployed, which is likely the case, this agent will be potentially be the SP1 version, and still reporting to the SP1 server.
Connect to each host, and remove the agent manually from the Add/Remove Programs dialog. Failure to remove the agent will cause VMM will complain that the agents are incompatible as soon as we being to execute the next step of the migration.
With the Hyper-V hosts ready, we can now have the target SCVMM 2012 R2 environment push the new agents to these hosts and complete its procedure to have these registered in VMM.
$runAsAccount = Get-SCRunAsAccount -Name "SCVMM Agent Management" $hostGroup = Get-SCVMHostGroup -Name "WS08R2" Add-SCVMHostCluster -Name "PDC-VM-CLUSTER1.diginerve.net" -RunAsynchronously -VMHostGroup $hostGroup -Reassociate $true -Credential $runAsAccount -RemoteConnectEnabled $true Add-SCVMHostCluster -Name "PDC-VM-CLUSTER2.diginerve.net" -RunAsynchronously -VMHostGroup $hostGroup -Reassociate $true -Credential $runAsAccount -RemoteConnectEnabled $true
After executing these commands, SCVMM will begin its work of exercising the refreshers and start enumerating the nodes in the clusters. This will take 15 to 20 minutes to complete, after which we will have a full list of VMs. However expect all of these to be in an “unsupported configuration” state. As the host networking is not yet known to SCVMM, we will set out to address this challenge in the next steps.
This following step is a general guidance only, as every environment will be quite different. How you implement your logical networks also will be your decision. If you are using the pre-2012 SP1 approach you will have a logical network per VLAN, which the tenants are using (as depicted in this code). Or if you are using the new 2012 SP1 approach you will have maybe one logical network for your tenant VLANs, which contains a site per VLAN.
Of course you can always mix and match, or migrate from the old approach to the new approach as you are ready. For my migration I need to create a range of VLANs from 2001 to 2099. Asimple PowerShell loop will come to the rescue here and get this instantiated for us.
$allHostGroups = @() $allHostGroups += Get-SCVMHostGroup -Name "Operations" for ($i=2001;$i -lt 2100; $i++) { $logicalNetwork = New-SCLogicalNetwork -Name "Tenant (VLAN's)" -LogicalNetworkDefinitionIsolation $true -EnableNetworkVirtualization $false -UseGRE $false -IsPVLAN $false $allSubnetVlan = @() $allSubnetVlan += New-SCSubnetVLan -VLanID $i New-SCLogicalNetworkDefinition -Name "Tenant (VLAN's)" -LogicalNetwork $logicalNetwork -VMHostGroup $allHostGroups -SubnetVLan $allSubnetVlan -RunAsynchronously }
Keeping with the network changes introduced in 2012 SP1, each of our logical networks, is now required to have a virtual machine network established which will be the true connection point for our VMs. These VM networks will have a simple one-to-one relationship with the sites of our logical networks and therefore can be defined again quite simply through the use of a loop in PowerShell.
for ($i=2001;$i -lt 2100; $i++) { $logicalNetwork = Get-SCLogicalNetwork -Name "VLAN$i" $vmNetwork = New-SCVMNetwork -Name "VLAN$i" -LogicalNetwork $logicalNetwork -IsolationType "VLANNetwork" $logicalNetworkDefinition = Get-SCLogicalNetworkDefinition -Name "VLAN$i" -LogicalNetwork $logicalNetwork $subnetVLAN = New-SCSubnetVLan -VLanID $i $vmSubnet = New-SCVMSubnet -Name "VLAN$i" -LogicalNetworkDefinition $logicalNetworkDefinition -SubnetVLan $subnetVLAN -VMNetwork $vmNetwork }
Our network definitions are now in place, so all that remains is for us to attach these to the virtual switch. Let’s point out again that I am not using a logical switch here, and instead using the old-style virtual switch. If I had chosen to use a logical switch, then I would need to just assign these network to the switch; in turn, once assigned to the hosts it would ensure that they are all kept in sync, which itself is a great reason to use a logical switch when possible.
As before with a simple loop, which needs to be repeated on every hosts (virtual switch again), tagging the interface hosting the vSwitch with the list of logical networks which it will support.
$vmHost = Get-SCVMHost -ComputerName PDC-VM-CLU1-H01 $virtualSwitch = Get-SCVirtualNetwork -Name "VM Switch Team" -VMHost $vmHost $JobGUID = ([System.Guid]::NewGuid()) $jobID = $JobGUID.Guid $vmHostNetworkAdapter = Get-SCVMHostNetworkAdapter -Name "TEAM : Team MRC1" -VMHost $vmHost Set-SCVMHostNetworkAdapter -VMHostNetworkAdapter $vmHostNetworkAdapter -Description "" -AvailableForPlacement $true -UsedForManagement $false -JobGroup $JobID for ($i=2001;$i -lt 2100; $i++) { $logicalNetwork = Get-SCLogicalNetwork -Name "VLAN$i" Set-SCVMHostNetworkAdapter -VMHostNetworkAdapter $vmHostNetworkAdapter -JobGroup $JobID -AddOrSetLogicalNetwork $logicalNetwork } Set-SCVMHost -VMHost $vmHost -JobGroup $JobID -RunAsynchronously -NumaSpanningEnabled $true
This one will take a few minutes to complete. And don’t forget to repeat it for every host in the cluster!
At this stage of the process, we have pretty much sorted out the basic requirements to get our VMs and hosts into the management scope, our next point of focus is our libraries. Following a very similar procedure to what we just completed we will reregister the agents on our library server to communicate with our new VMM environment.
Recall earlier that we needed to prepare our Hyper-V hosts as they were already registered to your SCVMM SP1 environment, now in a similar manner you will need to execute the same procedure on these servers to remove the old agents and prepare them for the new agent deployment. Yes, it’s manual!
The follow PowerShell script will then register the specific shares on your library hosts with the new VMM server.
$JobGUID = ([System.Guid]::NewGuid()) $jobID = $JobGUID.Guid $credential = Get-Credential Add-SCLibraryShare -Description "" -JobGroup $JobID -SharePath "\\PDC-FS-SMB01.diginerve.net\Libraries" Add-SCLibraryShare -Description "" -JobGroup "$JobID -SharePath "\\PDC-FS-SMB01.diginerve.net\Media" Add-SCLibraryShare -AddDefaultResources -Description "" -JobGroup $JobID -SharePath "\\PDC-FS-SMB01.diginerve.net\MSSCVMMLibrary" Add-SCLibraryServer -ComputerName "PDC-FS-SMB01.diginerve.net" -Description "" -JobGroup $JobID -RunAsynchronously -Credential $credential
Note that on the MSSCVMMLibrary share I am instructing VMM to update the default resources so that we have the latest versions of Server App-V and WebDeploy available to use.
The foundation work is now complete. VMM should essentially have a clean fabric with a lot of VMs that have no owners. In the next stage of the migration we will start to address all the metadata that we export from the existing environment and move to the new environment.