Datacenter & Cloud Consolidation and Migration

Double-Take Move - Operations Guide

Table of Contents

1 Overview....................................................................................................62 Workflow Overview....................................................................................7

2.1 Discovery Process..........................................................................................82.2 Source Server Activities.................................................................................82.3 Target Server Activities..................................................................................9

3 Migration Guide........................................................................................103.1 Discovery Process........................................................................................103.2 Discovering Virtual Machine........................................................................103.3 Discovering Hyper-V Servers.......................................................................113.4 Discovering Hyper-V Virtual Networks.........................................................113.5 Discovering VMware Datacenters................................................................123.6 Discovering Windows Servers from Active Directory (Optional)..................133.7 Creating a Service Request (Migrating a Server).........................................14

3.7.1 Migrating a Single server..............................................................................153.8 Completing a Request..................................................................................20

3.8.1 VM Verification and Configuration...............................................................203.8.2 Completing a Change Request from Service Manager..............................213.8.3 Completing a Service Request from Service Manager..............................22

4 Troubleshooting Migration Failures..........................................................234.1 System Center 2012 R2 Service Manager....................................................234.2 System Center 2012 R2 Orchestrator..........................................................294.3 Double-Take Console...................................................................................32

5 Additional Considerations........................................................................345.1 vCenter Permissions....................................................................................345.2 Dynamic Disks.............................................................................................345.3 Dynamic Memory.........................................................................................345.4 Additional Configurations.............................................................................34

6 Large Scale Considerations......................................................................35

7 Known Issues...........................................................................................367.1 Problem 1: .Net 3.5 does not automatically install on Windows Server 2012 R2 and Windows 2003...........................................................................................367.2 Problem 2: Migration gets stuck at Approve Reboot....................................377.3 Problem 3: Orchestrator Runbook cannot find the Source Virtual Machine. 377.4 Problem 4: VMs with IDE disks do not get discovered..................................387.5 Problem 5: Hyper-V Integration Tools do not install Windows Server 2003 387.6 Problem 6: Same virtual machine appear twice on SMPortal for migration. 387.7 Problem 7: Service Manager Portal shows ESX servers along with Hyper-V as Target for Migration..............................................................................................387.8 Other Considerations...................................................................................39

1 OverviewThe purpose of this document is to provide an operations manual to migrate workloads from a VMware platform to a Hyper-V platform using the Double-Take Move System Center Integration Toolkit.This document assumes basic familiarity with the operation of the VMware vCenter server, System Center 2012 R2 Service Manager, System Center 2012 R2 Orchestrator, System Center 2012 R2 Virtual Machine Manager and Hyper-V. This document also assumes that the build process for the Double-Take Move System Center Integration Toolkit was completed in accordance with the Build Guide.

4

2 Workflow OverviewThe Double-Take Move System Center Integration Toolkit architecture and steps for migration of Virtual Machine from VMware to Hyper-V platform are shows in the picture below

1. You must install Double-Take Move on the Orchestrator server and on the Hyper-V server that will host your migrated virtual machines.

2. Integration packs and Runbooks must also be installed on the Orchestrator server, and the Double-Take Move Management Pack must be installed on the Service Manager server.

3. VMware hosts, VMware virtual machines, Hyper-V hosts, and Hyper-V networks are automatically discovered based on Orchestrator Integration Packs configuration settings.

4. Double-Take Move Service Requests (single server or multiple servers) are created through the Service Manager Portal installed on the SharePoint server.

5. The Service Manager server submits the Service Request, triggering Orchestrator Runbooks which create Change Requests for each server selected for migration.

5

6. Runbooks on the Orchestrator server continually monitor the status of the Change Request activities.

7. Based on the status of the activity, the following actions are performed.a. Install Double-Take Move on the source virtual machine, if necessary.b. Activate Double-Take Move on the source virtual machine, if necessary. c. Reboot the source virtual machine, if necessary. d. Create the Double-Take job.

8. The Double-Take job will create the replica virtual machines on the Hyper-V host, mount the .vhd or .vhdx files to the Hyper-V host, and then mirror and replicate data from the source virtual machine to the mount point on the Hyper-V host.

9. Upon approval, the virtual machine is tested or migrated. If the virtual machine is migrated, the Double-Take job is deleted.

The following sections provide detailed description of activities involved in migration of Virtual Machine from VMware to Hyper-V using Double take System Center Integration Toolkit.

2.1 Discovery Process1. The Orchestrator Discovery Runbooks discover VMware Virtual machines by

querying VMware VCenter. The discovered Virtual Machines are populated as CIs in Service Manager

2. The Runbooks also gather the information about hardware configuration of each Virtual Machine

3. The discovery process also gathers information about Guest Operating Systems

4. The Orchestrator discovery Runbooks discovery the Hyper-V servers and their network configuration by querying Virtual Machine Manager.

5. The discovered Hyper-V servers and Hyper-V Networks are populated as CIs in Service Manager

2.2 Source Server Activities1. Once the Service Request is Submitted, the Orchestrator Runbook creates a

corresponding/related Change Request2. The inputs provided in Service Request are validated3. The VMware tools version is verified on the Source VM4. Checks the presence of Double Take software on the Source VM5. Snapshot of Source VM is taken6. VMware tools are uninstalled7. Double-Take software is installed on the Source VM. .Net Framework is

installed if it is not already installed on the VM.

6

8. The pending Reboot of the source Server is checked. If there is a pending Reboot, a manual approval is required for reboot of the server

9. Once the approval is done, the Source Server is rebooted

2.3 Target Server Activities10.Double-Take move creates a replication job and started synchronizing Source

VM with Target VM11.Double-Take keeps the source and Target VM in Sync until the user approves

the cut-over to Hyper-V12.The Target VM Configuration is Manually verified13.Once the Cutover is approved, the source VM is shut down and migrated VM

on Hyper-V is started.14.Based on the configuration, the Source VM could be deleted from the ESX

server.15.At this point, the Service Request is completed and closed.

7

3 Migration Guide

3.1 Discovery ProcessThe discovery of Virtual Machines, Hyper-V hosts, Hyper-V Networks, Physical Servers and VMware datacenter is done by following Orchestrator CMDB Discovery Runbooks:

3.2 Discovering Virtual MachineThe discovery of Virtual machines from VMware Environment is done by the Runbook 20.01 – Discover VMware VMs.

This Runbook performs the following activities:

8

1. This Runbook runs at a configurable interval and queries VMware VCenter Server for the list of virtual machines in the environment.

2. It gathers basic information about each VM like memory, CPU, disks, etc.3. Gathers information about ESX host the Virtual Machine resides on.4. Creates a new Virtual machine CI in Service Manager

Note:At any given time, the Orchestrator Runbook can only query one vCenter Server

3.3 Discovering Hyper-V ServersThe discovery of Virtual machines from Hyper-V Environment is done by the Runbook 20.02 – Discover Hyper-V Hosts.

This Runbook performs the following activities:16.This Runbook runs at a configurable interval and queries System Center 2012

R2 Virtual Machine Manager for the list of Hyper-V Hosts in the environment. 17.It gathers basic information about each Hyper-V Hosts like memory, CPU,

disks, etc.18.Triggers the discovery of Virtual Networks on the hyper-V Servers19.Creates a new Hyper-V Host CI in Service Manager

3.4 Discovering Hyper-V Virtual NetworksThe discovery of Hyper-V Virtual Networks is done by the Runbook 20.03 – Discover Hyper-V Virtual Networks

9

This Runbook performs the following activities:1. This is triggered by Discovery –Hyper-V hosts Runbook. 2. It gathers information about Virtual networks on each Hyper-V Hosts3. Creates a new Hyper-V Host Virtual Networks CI in Service Manager

3.5 Discovering VMware DatacentersThe discovery of VMware Datacenters is done by the Runbook – 20.04 – Discover VMware Datacenters

10

This Runbook performs the following activities:1. This Runbook runs at a configurable interval and queries VMware VCenter

Server for the list of VMware Datacenters in the environment. 2. Creates a new Datacenter CI in Service Manager

Note:At any given time, the Orchestrator Runbook can only query one VCenter Server

3.6 Discovering Windows Servers from Active Directory (Optional)

The discovery of Windows Servers from Active directory is done by the Runbook – 20.05 – Discovery Windows Servers – Active Directory. This is an optional discovery to discover the Servers that are not running on VMware Platform like Physical Servers

11

This Runbook performs the following activities:20.This Runbook runs at a configurable interval and queries Active Directory for

the list of Servers in the environment. 21.Gathers basic information about these servers like memory, CPU, make,

model, etc.22.Creates a CI in Service Manager for each discovered server.

3.7 Creating a Service Request (Migrating a Server)In the Service Manager self-service portal (SMPortal), you will see the different types of migration requests. These Service Requests are created when you import the double take management pack in Service Manager. This Management pack is unsealed in order to allow you to make changes in Service Request Templates and configurations.

Double-Take Move - Migrate any Windows Server to Hyper-V - Multiple Servers - This request allows you to select multiple Windows servers for migration, tracking them under a single Service Request, which generates a Change Request for each server selected. You will be presented with a list of servers that were discovered in Active Directory through an Orchestrator Runbook discovery process. The migrated (replica) servers will

12

use the same configuration for the number of processors and memory as the source server.

Double-Take Move - Migrate any Windows Server to Hyper-V - Single Server - This request allows you to select a single Windows server for migration, tracking it under a single Service Request, which generates a Change Request for the selected server. You will be presented with a list of servers that were discovered in Active Directory through an Orchestrator Runbook discovery process. This request allows you to customize various migrated (replica) settings such as the number of processors, amount of memory, and the source volumes to replicate.

Double-Take Move - Migrate VMware VM to Hyper-V - Multiple Servers - This request allows you to select multiple VMware virtual machines for migration, tracking them under a single Service Request, which generates a Change Request for each server selected. You will be presented with a list of servers that were discovered on your VMware host through an Orchestrator runbook discovery process. The migrated (replica) servers must use the same configuration for the number of processors and memory as the source virtual machines. You will have the option to uninstall VMware Tools and take a VMware snapshot before making any changes to the source virtual machine.

Double-Take Move - Migrate VMware VM to Hyper-V - Single Server - This request allows you to select a single VMware virtual machine for migration, tracking it under a single Service Request, which generates a Change Request for the selected server. You will be presented with a list of servers that were discovered on your VMware host through an Orchestrator Runbook discovery process. This request allows you to customize various migrated (replica) settings such as the number of processors, amount of memory, and the source volumes to replicate. You will have the option to uninstall VMware Tools and take a VMware snapshot before making any changes to the source virtual machine.

The following example is for a single server request for a VMware virtual machine. This workflow addresses all available options. If you are using one of the other workflows, you may not be presented with each of these options.

3.7.1 Migrating a Single server1. Login to the SMPortal on your SharePoint server.2. Click List View and the Double-Take Request offerings will be displayed.

13

3. Click Double-Take Move - Migrate VMware to Hyper-V - Single Server.4. Click Go to request on the right side of the page 5. Although there are many fields on the first screen, only Title is required and

used. Depending on your screen reSolution, you may see two scroll bars, and you may need to use both to see all of the options and to click the navigation buttons at the bottom of the window.

6. Enter the Title, which will be the name of the Service Request that is created. Since the other fields are not used by Double- Take Move, you may skip them.

7. Click Next to continue.8. Select the source virtual machine that you want to migrate. All virtual

machines are listed even if they are unsupported or powered off. 9. You can search for a server or click Next at the bottom of the screen to

browse page by page. For the single server request, you will only be able to select one machine. For the multiple server request, you will be able to select multiple machines.

14

10.Select the desired values for the replica virtual machine on the target. Not all of the fields are applicable to non-VMware migrations and to multiple server requests. For multiple server migration requests, the default values will be used.

a. Target Virtual Machine - Desired CPU Count—This is the number of CPUs to create on the replica virtual machine. The default is zero (0), which indicates the replica virtual machine will be configured identically to the source virtual machine. Modify this value if desired.

b. Target Virtual Machine - Desired Memory—This is the amount of memory assigned to the replica virtual machine. The default is zero (0), which indicates the replica virtual machine will be configured identically to the source virtual machine. Modify this value if desired. If left at the

15

default of zero then it will match the configuration of the source machine.

c. Take snapshot of Source VM before making changes—Specify YES to have VMware take a snapshot of the source virtual machine before installing Double-Take Move. The default setting is YES

d. Uninstall VMware Tools from Source VM before installing Double-Take—Specify YES to have VMware Tools removed on the source virtual machine before installing Double-Take Move. The default setting is YES.

e. Volumes to Migrate—Specify the volumes you want to migrate, using a comma separated list of volume letters formatted as letter colon backslash, for example C:\. Leave the field blank if you want all of the volumes on the source to be migrated.

11.Select the target Hyper-V host from the list of hosts managed by System Center Virtual Machine Manager. Select the Hyper-V host with Double-Take Move installed with the Double-Take Move target activation code

12.Select the Hyper-V network to attach to the migrated source’s NICs. You must click Refresh after selecting the Hyper-V host to see the virtual network interface names.

13.Specify the destination of the replica virtual machine, target route, and compression

16

a. Hyper-V Host Server: Virtual Machine Destination Path—This is the path where the virtual machines will be created. A sub-folder with the name of the source will be created under this path for each machine migrated. For example, if you specify D:\Migrated VMs\, the source virtual machine called Source1 will be sent to D:\Migrated VMs\Source1\ and the source virtual machine called Source2 will be sent to D:\Migrated VMs\Source2.

b. Target Route for Migration Data—If desired, enter an IP address for the Double-Take Move job to send data to on the target. If the field is left blank, Double-Take Move will automatically determine the route.

c. Compress Migration Data—Specify if you want to compress the data the Double-Take Move sends to the target. Typically, compression is enabled in a WAN environment where no other WAN accelerators are present. Enabling this option is equivalent to the medium compression level in Double-Take Move. The default setting is NO.

14.Select the activation code to use on the source. If Double-Take Move is already installed with an activated Double-Take Move source code, this field will not be used, even if it is configured

15.Review the job options and click Submit to continue. A Service Request will be created and follow the activities located within the request.

17

3.8 Completing a RequestBy default, when the approval is given for the live cutover it will cause Double-Take Move to initiate the live cutover. Once completed, the Double-Take Move job is deleted and the Change Request completes. When the Change Request is completed, the Service Request also completes. However, depending on changes to the defaults, you may have to manually complete a Service Request

3.8.1 VM Verification and ConfigurationYou can open the use Hyper-V console to verify that your migrated virtual machines are on the Target Host you specified earlier. You must verify the hardware configuration of the migrated virtual machine to check if it is same as the source virtual machine.

Depending upon the configuration and Operating System of the source VM, you may need to perform the following activities:

18

23.Convert dynamically expanding disk to fixed size disk if necessary.24.Install/Upgrade Hyper-V integration tools25.Verify/Change the IP address of the Virtual machines26.Check if the disks are connected to the correct disk controller (IDE or SCSI)27. Set dynamic memory for the Virtual machine if necessary28.Configure Windows Server 2012 R2 advanced features like Quality of Service,

VLAN, Bandwidth management, VM affinity, network virtualization, etc. as necessary

3.8.2 Completing a Change Request from Service ManagerOnce you have verified the configuration of the migrated Virtual machine, perform the following steps from Service Manager Console to complete the Change Request:

1. From the Service Manager Console, expand Work Items, expand Change Management, and select All Change Requests.

2. Double-click on the Change Request you would like to complete.3. Click on the Activities tab. It is easier to view the activities if you select the

List View in the upper right corner of the activities pane.4. If there are activities that need approval and are in progress, open the

activities and select Approve.5. Enter a comment and click OK.6. If there are activities that are manual, are not skipped, and are in progress,

open the activities and select Mark as Completed7. Enter a comment and click OK8. For all other activities that are in progress or pending, right-click and select

Skip Activity if you want to skip that activity and complete the Change Request. If you skip an activity, that task will not be performed and you may have to perform that task manually

9. Enter the comment and click OK.10.Click OK to complete the change request.

19

3.8.3 Completing a Service Request from Service ManagerPerform the following steps from Service Manager Console to complete the Service Request:

29.From the Service Manager Console, expand Work Items, expand Service Request Fulfillment, and select All Open Service Requests.

30.Double-click on the Service Request you would like to complete.31.Click on the Activities tab. It is easier to view the activities if you select the

List View in the upper right corner of the activities pane.32.If there are activities that need approval and are in progress, open the

activities and select Approve.33.Enter a comment and click OK.34.If there are activities that are manual, are not skipped, and are in progress,

open the activities and select Mark as Completed.35.Enter a comment and click OK.36.For all other activities that are in progress or pending, right-click and select

Skip Activity if you want to skip that activity and complete the Service Request. If you skip an activity, that task will not be performed and you may have to perform that task manually.

37.Enter a comment and click OK.38.Click OK to complete the service request.

At this point, the Service Request is complete and the virtual machine has been migrated to Hyper-V.

20

4 Troubleshooting Migration FailuresThere is no separate logging in Double-Take System Center integration toolkit apart from settings activity status in System Center 2012 R2 Service Manager. However, in order to diagnose and troubleshoot the cause of failures, you can check the status of Orchestrator Runbooks and Double Take console as well.

4.1 System Center 2012 R2 Service ManagerOnce the service request and change request is created, Orchestrator Runbooks updates the status of each activity in the Change Request based on the result of each activity. You can either view the status of each Service Request from Self- service portal or check the status from Service Manager Console.Perform the following steps to view the status of failed Service Request and Corresponding Change Request:

39.Open the Service Manager Console40.Go to Work Items section.41.Expand Service Request Fulfillment42.Click on “Failed Service Requests”

21

43.Open the Service Request that has failed

44.Click on Activities tab

22

45.Observe the activity that has failed in the Service Request46.Click on Related Items47.Depending upon the stage of failure, you may or may not see corresponding

Change Request under “Work items” section on this tab

23

24

48.If the Change Request has been created, select the Change Request and click on View

49.This will open the corresponding Change Request50.Click on Activities tab of the Change Request51.Observe the Activity that has failed in the Change Request52.Open the failed Activity and identify the corresponding Orchestrator Runbook

that has failed.

25

4.2 System Center 2012 R2 OrchestratorOnce you have identified the failed Runbook from Service Manager:

1. Open the Orchestrator Runbook designer and 2. Navigate to the failed Runbook.

3. Open the appropriate event from log history. The timestamp on the event should be a good indicator.

4. From the log event, identify the object/activity in the Runbook that has failed.

26

5. Increase the logging of the Runbook if you need more information to identify the cause of the failure.

27

28

4.3 Double-Take ConsoleYou may also use the Double Take console if there is a failure in Double Take Job. The double take console is installed on the Orchestrator Server.

53.Open the Double Take console on the Orchestrator Server.54.Click on Manage Servers.55.The Console shows the list of Source and Target servers

56.Click on Manage Jobs57.The console shows the list of all jobs and their statuses.

58.Right-Click the failed job and click on Job details

29

59.Click on View Server logs to get detailed information about the error.

30

5 Additional Considerations

5.1 vCenter PermissionsDouble-take Move System Center Integration Toolkit uses System Center Integration Pack for VMware to discover Virtual Machines and Datacenters in VMware Environment. In order to make sure of successful discovery of Virtual Machines and datacenters, the VMware Integration pack must be configured with an account that has at least “Read” access on the entire VMware Environment. However, additional rights are required to perform management activities like Taking Snapshots during the migration process

5.2 Dynamic DisksAfter converting Virtual machines from VMware Environment to Hyper-V environment, Double-Take move converts the Thick disk in VMware into dynamic disk on Hyper-V. Once the conversion is complete, the dynamic Disk on Hyper-V should be converted into fixed sized disk as per the workload requirement.

5.3 Dynamic MemoryDouble-Take move does not take into account the Dynamic memory settings of a Virtual machine in VMware environment. After conversion, it configures the static memory on the Hyper-V for all converted Virtual machines. You must manually configure dynamic memory on converted VM based on the workload requirements

5.4 Additional ConfigurationsIn order to take full advantage of migration to Windows Server 2012 R2 Hyper-V, you may consider making following configuration changes on the migrated VM:

60.Configure QoS for managing IOPs61.Configured VLAN and Bandwidth management for managing network traffic62.Configure NIC Teaming63.Configure VM affinity if necessary64.Installing or upgrading Hyper-V Integrating Services

31

6 Large Scale ConsiderationsSome additional considerations for a large-scale migration include the following:

The target Hyper-V Server could become a bottleneck for large environments. Consider using Hyper-V clusters and live migration to reduce the load on a single target Hyper-V server.

If you are migrating multiple Virtual Machines, select the virtual machines for different ESX servers instead of choosing all from a single ESX host.

Carefully plan the sizing of System Center Components and Hyper-V servers. Plan for network bottlenecks that may occur during transfer of data from

Source Virtual machines to destination Hyper-V.

32

7 Known Issues

7.1 Problem 1: .Net 3.5 does not automatically install on Windows Server 2012 R2 and Windows 2003

Description - During the migration process, Double-Take move software must be installed on the source server. .Net Framework is a prerequisite for Double-Take Software. This is done automatically by Double Take Move Integration pack object - “Install- Double Take”

33

Cause - The “Install Double-Take” object cannot be used to install .Net framework on Window Server 2012 R2 and Windows Server 2003.Possible Solution - Install .Net Framework on Windows Server 2003 and Windows Server 2012 R2 before migration.

7.2 Problem 2: Migration gets stuck at Approve Reboot Cause - The migration from VMware to Hyper-V is supposed to be with minimal down time. However, in case the Source Server has a pending reboot, it must be rebooted prior to Synchronization with target Hyper-V host. In such cases, the Server would need two reboots for migration to complete successfully.Possible Solution - Approve the Server reboot as per the change control process.

7.3 Problem 3: Orchestrator Runbook cannot find the Source Virtual Machine

Description: The Orchestrator Runbook uses VMware vSphere integration pack to perform operations like discovery, snapshots, etc.Cause: The integration pack connection must be named as vSphere for VMware vSphere Integration Pack. If the connection name is different, the Orchestrator Runbook will not be able to find the Virtual Machines on vCenter Server. Additionally, the Orchestrator Runbook can only work with one vCenter Server at a time. You must change the connection setting to point to other vCenter Server if you want to migrate Virtual machines from any other vCenter environment.Solution:Make sure that integration pack connection for VMware vSphere is named correctly.

34

7.4 Problem 4: VMs with IDE disks do not get discovered

Description - The Orchestrator Runbook uses VMware vSphere integration pack to perform operations like discovery, snapshots, etc. However, the Virtual Machines with IDE disks do not get discovered.Cause - The vSphere integration pack uses the object Get VM Properties to discover the properties of the Virtual Machine. However this object fails if there Virtual machine has an IDE drive attached to the Virtual Machine. Solution - Modify the configuration of the Virtual machine to convert disks attached to IDE drive to SCSI drive.

7.5 Problem 5: Hyper-V Integration Tools do not install Windows Server 2003

Solution - There is not automation in Double-Take System Center Integration Toolkit to install Hyper-V integration tools. This must be done manually after migration process is complete.

7.6 Problem 6: Same virtual machine appear twice on SMPortal for migration

Cause - This issue occurs if the hostname of the Virtual machine has changed after the discovery process has complete. This results in creation of multiple CIs in Service Manager for the same VM.Solution - Delete the Virtual machine CI in Service Manager that has old hostname.

7.7 Problem 7: Service Manager Portal shows ESX servers along with Hyper-V as Target for Migration

Cause - This issue occurs if Virtual machine manager is configured to manager VSphere ESX servers. During the discovery process, double take discovery would discover ESX servers along with Hyper-V and populate Service Manager CIs. These CIs reflect as Targets on the SM portal.Solution - This is a known issue with Double Take discovery. Currently you need to ignore ESX servers from the list of Targets

35

7.8 Other Considerations1. On Windows 2003 machines, the VMware tools install successfully, but the

entry remains in Add/Remove Program. This could be removed after migration is complete from Add/Remove programs.

2. If the migration fails at a particular step/activity, the migration process can be restarted from the point of failure. This can be done by: Rt. Clicking the failed activity and selecting “Return to Activity”. This would trigger the Orchestrator Runbook to perform the failed activity again. However, this does not reset the status of original Service Request and causes skew in reporting.

3. The Double-Take migrations are hypervisor agnostic migrations. It shows the same results for VMs on vCenter 4.1 and vCenter 5.1

4. Adding or removing any Activity in Double Take Service request/Change Request is not recommended. A thorough testing must be done if there is a requirement to do so.

36