PageRenderTime 49ms CodeModel.GetById 15ms RepoModel.GetById 1ms app.codeStats 0ms

/articles/site-recovery/site-recovery-failback-azure-to-vmware-classic-legacy.md

https://gitlab.com/apachipa/azure-content
Markdown | 473 lines | 276 code | 197 blank | 0 comment | 0 complexity | 896c87d17e88bf3e9b1716cde5c4cc43 MD5 | raw file
  1. <properties
  2. pageTitle="Fail back VMware virtual machines and physical servers from Azure to VMware (legacy) | Microsoft Azure"
  3. description="This article describes how to fail back a VMware virtual machine that's been replicated to Azure with Azure Site Recovery."
  4. services="site-recovery"
  5. documentationCenter=""
  6. authors="ruturaj"
  7. manager="mkjain"
  8. editor=""/>
  9. <tags
  10. ms.service="site-recovery"
  11. ms.devlang="na"
  12. ms.tgt_pltfrm="na"
  13. ms.topic="article"
  14. ms.workload="storage-backup-recovery"
  15. ms.date="03/06/2016"
  16. ms.author="ruturajd@microsoft.com"/>
  17. # Fail back VMware virtual machines and physical servers from Azure to VMware with Azure Site Recovery (legacy)
  18. > [AZURE.SELECTOR]
  19. - [Azure Portal](site-recovery-failback-azure-to-vmware.md)
  20. - [Azure Classic Portal](site-recovery-failback-azure-to-vmware-classic.md)
  21. - [Azure Classic Portal (Legacy)](site-recovery-failback-azure-to-vmware-classic-legacy.md)
  22. The Azure Site Recovery service contributes to your business continuity and disaster recovery (BCDR) strategy by orchestrating replication, failover and recovery of virtual machines and physical servers. Machines can be replicated to Azure, or to a secondary on-premises data center. For a quick overview read [What is Azure Site Recovery?](site-recovery-overview.md)
  23. ## Overview
  24. This article describes how to fail back VMware virtual machines and Windows/Linux physical servers from Azure to your on-premises site after you've replicated from your on-premises site to Azure.
  25. >[AZURE.NOTE] This article describes a legacy scenario. You should only use the instructions in this article if you replicated to Azure using [these legacy instructions](site-recovery-vmware-to-azure-classic-legacy.md). If you set up replication using the [enhanced deployment](site-recovery-vmware-to-azure-classic-legacy.md) then follow the instructions in [this article](site-recovery-failback-azure-to-vmware-classic.md) to fail back.
  26. ## Architecture
  27. This diagram represents the failover and failback scenario. The blue lines are the connections used during failover. The red lines are the connections used during failback. The lines with arrows go over the internet.
  28. ![](./media/site-recovery-failback-azure-to-vmware/vconports.png)
  29. ## Before you start
  30. - You should have failed over your VMware VMs or physical servers and they should be running in Azure.
  31. - You should note that you can only fail back VMware virtual machines and Windows/Linux physical servers from Azure to VMware virtual machines in the on-premises primary site. If you're failing back a physical machine, failover to Azure will convert it to an Azure VM, and failback to VMware will convert it to a VMware VM.
  32. Here's how you set up failback:
  33. 1. **Set up failback components**: You'll need to set up a vContinuum server on-premises, and point it to the configuration server VM in Azure. You'll also set up a process server as an Azure VM to send data back to the on-premises master target server. You register the process server with the configuration server that handled the failover. You install an on-premises master target server. If you need a Windows master target server it's set up automatically when you install vContinuum. If you need Linux you'll need to set it up manually on a separate server.
  34. 2. **Enable protection and failback**: After you've set up the components, in vContinuum you'll need to enable protection for failed over Azure VMs. You'll run a readiness check on the VMs and run a failover from Azure to your on-premises site. After failback finishes you reprotect on-premises machines so that they start replicating to Azure.
  35. ## Step 1: Install vContinuum on-premises
  36. You'll need to install a vContinuum server on premises and point it to the configuration server.
  37. 1. [Download vContinuum](http://go.microsoft.com/fwlink/?linkid=526305).
  38. 2. Then download the [vContinuum update](http://go.microsoft.com/fwlink/?LinkID=533813) version.
  39. 3. Install the latest version of vContinuum. On the **Welcome** page click **Next**.
  40. ![](./media/site-recovery-failback-azure-to-vmware/image2.png)
  41. 4. On the first page of the wizard specify the CX server IP address and the CX server port. Select **Use HTTPS**.
  42. ![](./media/site-recovery-failback-azure-to-vmware/image3.png)
  43. 5. Find the configuration server IP address on the **Dashboard** tab of the configuration server VM in Azure.
  44. ![](./media/site-recovery-failback-azure-to-vmware/image4.png)
  45. 6. Find the configuration server HTTPS public port on the **Endpoints** tab of the configuration server VM in Azure.
  46. ![](./media/site-recovery-failback-azure-to-vmware/image5.png)
  47. 7. On the **CS Passphrase Details** page specify the passphrase that you noted down when you registered the configuration server. If you don't remember it check it in **C:\\Program Files (x86)\\InMage Systems\\private\\connection.passphrase** on the configuration server VM.
  48. ![](./media/site-recovery-failback-azure-to-vmware/image6.png)
  49. 8. In the **Select Destination Location** page specify where you want to install the vContinuum server and click **Install**.
  50. ![](./media/site-recovery-failback-azure-to-vmware/image7.png)
  51. 9. After installation completes, you can launch vContinuum.
  52. ![](./media/site-recovery-failback-azure-to-vmware/image8.png)
  53. ## Step 2: Install a process server in Azure
  54. You need to install a process server in Azure so that the VMs in Azure can send the data back to an on-premises master target server.
  55. 1. On the **Configuration Servers** page in Azure, select to add a new process server.
  56. ![](./media/site-recovery-failback-azure-to-vmware/image9.png)
  57. 2. Specify a process server name, and a name and password to connect to the virtual machine as an administrator. Select the configuration server to which you want to register the process server. This should be the same server you're using to protect and fail over your virtual machines.
  58. 3. Specify the Azure network in which the process server should be deployed. It should be the same network as the configuration server. Specify a unique IP address selected subnet and begin deployment.
  59. ![](./media/site-recovery-failback-azure-to-vmware/image10.png)
  60. 4. A job is triggered to deploy the process server.
  61. ![](./media/site-recovery-failback-azure-to-vmware/image11.png)
  62. 5. After the process server is deployed in Azure you can log into the server
  63. using the credentials you specified. Register the process server in the same way you registered the on-premises process server.
  64. ![](./media/site-recovery-failback-azure-to-vmware/image12.png)
  65. >[AZURE.NOTE] The servers registered during failback won't be visible under VM properties in Site Recovery. They are only visible under the **Servers** tab of the configuration server to which they're registered. It can take about 10-15 minutes until they the process server appears on the tab.
  66. ## Step 3: Install a master target server on-premises
  67. Depending on your source virtual machines operating system, you need to install a Linux or a Windows master target server on-premises.
  68. ### Deploy a Windows master target server
  69. A Windows master target is already bundled with vContinuum setup. When you install
  70. the vContinuum, a master server is also deployed on the same machine and
  71. registered to the configuration server.
  72. 1. To begin deployment, create an empty machine on-premises on the ESX host onto which you want to recover the VMs from Azure.
  73. 2. Ensure that there are at least two disks attached to the VM one is used for the operating system and the other is used for the retention drive.
  74. 3. Install the operating system.
  75. 4. Install the vContinuum on the server. This also completes installation of the master target server.
  76. ### Deploy a Linux master target server
  77. 1. To begin deployment, create an empty machine on-premises on the ESX host onto which you want to recover the VMs from Azure.
  78. 2. Ensure that there are at least two disks attached to the VM one is used for the operating system and the other is used for the retention drive.
  79. 3. Install the Linux operating system. The Linux master target system should not use LVM for root or retention storage spaces. A Linux master target server is configured to avoid LVM partitions/disks discovery by default.
  80. 4. Partitions that you can create:
  81. ![](./media/site-recovery-failback-azure-to-vmware/image13.png)
  82. 5. Carry out the below post installation steps before beginning the master target installation.
  83. #### Post OS Installation Steps
  84. To get the SCSI IDs for each of SCSI hard disk in a Linux virtual machine,
  85. enable the parameter disk.EnableUUID = TRUE as follows:
  86. 1. Shut down your virtual machine.
  87. 2. Right-click the VM entry in the left-hand panel > **Edit Settings**.
  88. 3. Click the **Options** tab. Select **Advanced\>General item** > **Configuration Parameters**. The **Configuration Parameters** option is only available when the machine is shut down.
  89. ![](./media/site-recovery-failback-azure-to-vmware/image14.png)
  90. 4. Checks whether a row with **disk.EnableUUID** exists. If it does and is set to **False** then set it to **True **(not case sensitive). If exists and is set to true, click **Cancel** and test the SCSI command inside the guest operating system after it's booted up. If doesn't exist click **Add Row.**
  91. 5. Add disk.EnableUUID in the **Name** column. Set its value as TRUE. Don't add the above values along with double-quotes.
  92. ![](./media/site-recovery-failback-azure-to-vmware/image15.png)
  93. #### Download and install the additional packages
  94. NOTE: Make sure the system has internet connectivity before downloading and installing the additional packages.
  95. \# yum install -y xfsprogs perl lsscsi rsync wget kexec-tools
  96. This command downloads these 15 packages from CentOS 6.6
  97. repository and installs them:
  98. bc-1.06.95-1.el6.x86\_64.rpm
  99. busybox-1.15.1-20.el6.x86\_64.rpm
  100. elfutils-libs-0.158-3.2.el6.x86\_64.rpm
  101. kexec-tools-2.0.0-280.el6.x86\_64.rpm
  102. lsscsi-0.23-2.el6.x86\_64.rpm
  103. lzo-2.03-3.1.el6\_5.1.x86\_64.rpm
  104. perl-5.10.1-136.el6\_6.1.x86\_64.rpm
  105. perl-Module-Pluggable-3.90-136.el6\_6.1.x86\_64.rpm
  106. perl-Pod-Escapes-1.04-136.el6\_6.1.x86\_64.rpm
  107. perl-Pod-Simple-3.13-136.el6\_6.1.x86\_64.rpm
  108. perl-libs-5.10.1-136.el6\_6.1.x86\_64.rpm
  109. perl-version-0.77-136.el6\_6.1.x86\_64.rpm
  110. rsync-3.0.6-12.el6.x86\_64.rpm
  111. snappy-1.1.0-1.el6.x86\_64.rpm
  112. wget-1.12-5.el6\_6.1.x86\_64.rpm
  113. NOTE: If the source machine uses Reiser or XFS filesystem for the root or boot
  114. device, then following packages should be downloaded and installed on
  115. Linux master target prior to protection.
  116. \# cd /usr/local
  117. \# wget
  118. <http://elrepo.org/linux/elrepo/el6/x86_64/RPMS/kmod-reiserfs-0.0-1.el6.elrepo.x86_64.rpm>
  119. \# wget
  120. <http://elrepo.org/linux/elrepo/el6/x86_64/RPMS/reiserfs-utils-3.6.21-1.el6.elrepo.x86_64.rpm>
  121. \# rpm -ivh kmod-reiserfs-0.0-1.el6.elrepo.x86\_64.rpm
  122. reiserfs-utils-3.6.21-1.el6.elrepo.x86\_64.rpm
  123. \# wget
  124. <http://mirror.centos.org/centos/6.6/os/x86_64/Packages/xfsprogs-3.1.1-16.el6.x86_64.rpm>
  125. \# rpm -ivh xfsprogs-3.1.1-16.el6.x86\_64.rpm
  126. #### Apply custom configuration changes
  127. Before applying these changes make sure you've completed the previous section, then follow these steps:
  128. 1. Copy the RHEL 6-64 Unified Agent binary to the newly created OS.
  129. 2. Run this command to untar the binary: **tar -zxvf \<File name\>**
  130. 3. Run this command to give permissions: \# **chmod 755 ./ApplyCustomChanges.sh**
  131. 4. Run the script: **\# ./ApplyCustomChanges.sh**. Run the script only once on the server. Restart the server after the script runs.
  132. ### Install the Linux server
  133. 1. [Download](http://go.microsoft.com/fwlink/?LinkID=529757) the installation file.
  134. 2. Copy the file to the Linux Master Target virtual machine using an sftp client utility of your choice. Alternately you can log onto the Linux master target virtual
  135. machine and use wget to download the installation package from the
  136. provided link
  137. 3. Log onto the Linux master target server virtual machine using an ssh
  138. client of your choice
  139. 4. If you're connected to the Azure network on which you deployed your
  140. Linux master target server through a VPN connection then use the
  141. internal IP address for the server that you can find in the
  142. virtual machine **Dashboard** tab, and port 22 to connect to the Linux master
  143. target Server using Secure Shell.
  144. 5. If you're connecting to the Linux master target server over a public
  145. internet connection use the Linux master target servers public virtual
  146. IP address (from the virtual machines **Dashboard** tab) and the public
  147. endpoint created for ssh to login to the Linux servder.
  148. 6. Extract the files from the gzipped Linux master target Server installer
  149. tar archive by running: *tar xvzf Microsoft-ASR\_UA\_8.2.0.0\_RHEL6-64\** from the directory that contains the installer file.
  150. ![](./media/site-recovery-failback-azure-to-vmware/image16.png)
  151. 7. If you extracted the installer files to a different directory change
  152. to the directory to which the contents of the tar archive were
  153. extracted. From this directory path run sudo ./install.sh.
  154. ![](./media/site-recovery-failback-azure-to-vmware/image17.png)
  155. 8. When prompted to choose a primary role select **2 (Master Target)**. Leave the other interactive install options at their default values.
  156. 9. Wait for installation to continue and the Host Config
  157. Interface to appear. The Host Configuration utility for the Linux master
  158. sarget Server is a command line utility. Dont resize the ssh client
  159. utility window. Use the arrow keys to select the **Global** option and press
  160. ENTER on your keyboard.
  161. ![](./media/site-recovery-failback-azure-to-vmware/image18.png)
  162. ![](./media/site-recovery-failback-azure-to-vmware/image19.png)
  163. 10. In the field **IP** enter the Internal IP address of the configuration server (you can find it in the **Dashboard** tab of the configuration server VM) and press ENTER. In **Port** enter **22** and press ENTER.
  164. 11. Leave **Use HTTPS** as **Yes**, and press ENTER.
  165. 12. Enter the Passphrase that was generated on the configuration server. If you're using a PUTTY client from a Windows machine to ssh to the Linux virtual machine you can use Shift+Insert to paste the contents of the clipboard. Copy the Passphrase to the local clipboard using Ctrl-C and use Shift+Insert to paste it. Press ENTER.
  166. 13. Use the right arrow key to navigate to quit and press ENTER. Wait for installation to complete.
  167. ![](./media/site-recovery-failback-azure-to-vmware/image20.png)
  168. If for some reason you failed to register your Linux master target
  169. server to the configuration server you can do so again by running the
  170. host configuration utility from /usr/local/ASR/Vx/bin/hostconfigcli (you'll
  171. first need to set access permissions to this directory by running chmod as a super user).
  172. #### Validate master target registration
  173. You can validate that the master target server was registered successfully
  174. to the configuration server in Azure Site Recovery vault > **Configuration Server** > **Server Details**.
  175. >[AZURE.NOTE] After registering the master target server, if you receive configuration errors that the virtual machine might have been deleted from Azure or that endpoints are not properly configured, this is because although the master target configuration is detected by the Azure dndpoints when the master target is deployed in Azure, this isn't true for an on-premises master target server on-premises. This won't affect failback and you can ignore these errors.
  176. ## Step 4: Protect the virtual machines to the on-premises site
  177. You need to protect VMs to the on-premises site before you fail back.
  178. ### Before you begin
  179. When a VM is failed over to Azure, it adds an extra temp drive for page
  180. file. This is an extra drive that is typically not required by your
  181. failed over VM since it might already have a drive dedicated for the
  182. page file. Before you begin reverse protection of the virtual machines, you need to
  183. ensure that this drive is taken offline so that it does not get
  184. protected. Do this as follows:
  185. 1. Open Computer Management and select Storage Management so that it lists the disks online and attached to the machine.
  186. 2. Select the temporary disk attached to the machine and choose to bring it offline.
  187. ### Protect the VMs
  188. 1. In the Azure portal, check the states of the virtual machine to ensure that they're failed over.
  189. ![](./media/site-recovery-failback-azure-to-vmware/image21.png)
  190. 2. Launch vContinuum on your machine.
  191. ![](./media/site-recovery-failback-azure-to-vmware/image8.png)
  192. 3. Click **New Protection** and select the operation system type, the
  193. 4. In the new window that open select the **OS type** > **Get Details** for the VMs you want to fail back. In **Primary server details**, identify and select the virtual machines that you want to protect. VMs are listed under the vCenter host name that they were on before failover.
  194. 5. When you select a virtual machine to protect (and it has already failed over to Azure) a pop-up window provides two entries for the virtual machine. This is because the configuration server detects two instances of the virtual machines registered to it. You need to remove the entry for the on-premises VM so that you can protect the correct VM. To identify the correct Azure VM entry here, you can log into the Azure VM and go to C:\Program Files (x86)\Microsoft Azure Site Recovery\Application Data\etc. In the file drscout.conf , identify the host ID. In the vContinuum dialog, keep the entry for which you found the host ID on the VM. Delete all other entries. To select the correct VM you can refer to its IP address. The IP address range on-premises will be the on-premises VM.
  195. ![](./media/site-recovery-failback-azure-to-vmware/image22.png)
  196. ![](./media/site-recovery-failback-azure-to-vmware/image23.png)
  197. 6. On the vCenter server stop the virtual machine. You can also delete the VMs on-premises.
  198. 7. Then specify the on-premises MT server to which you want to protect the VMs. To do this, connect to the vCenter server to which you want to fail back.
  199. ![](./media/site-recovery-failback-azure-to-vmware/image24.png)
  200. 8. Select the master target server based on the host to which you want to recover the VM.
  201. ![](./media/site-recovery-failback-azure-to-vmware/image24.png)
  202. 9. Provide the replication option for each of the virtual machines. To do this you need to select the recovery side datastore to which the VMs will be recovered. The table summarizes the different options you need to provide for each VM.
  203. ![](./media/site-recovery-failback-azure-to-vmware/image25.png)
  204. **Option** | **Option recommended value**
  205. ---|---
  206. Process server IP address | Select the process server deployed in Azure
  207. Retention size in MB|
  208. Retention value | 1
  209. Days/Hours | Days
  210. Consistency interval | 1
  211. Select target datastore | The datastore available on the recovery site. The data store should have enough space, and be available to the ESX host on which you want to restore the virtual machine.
  212. 10. Configure the properties that the virtual machine will acquire after failover to on-premises site. The properties are summarized in the following table.
  213. ![](./media/site-recovery-failback-azure-to-vmware/image26.png)
  214. **Property** | **Details**
  215. ---|---
  216. Network configuration| For each network adapter detected, select it and click **Change** to configure the failback IP address for the virtual machine.
  217. Hardware Configuration| Specify the CPU and the memory for the VM. Settings can be applied to all the VMs you are trying to protect. To identify the correct values for the CPU and memory, you can refer to the IAAS VMs role size and see the number of cores and memory assigned.
  218. Display name | After failback to on-premises, you can rename the virtual machines as they'll appear in the vCenter inventory. The default name is the virtual machine computer host name. To identify the VM name, you can refer to the VM list in the Protection group.
  219. NAT Configuration | Discussed in detail below
  220. ![](./media/site-recovery-failback-azure-to-vmware/image27.png)
  221. #### Configure NAT settings
  222. 1. To enable protection of the virtual machines, two communication channels need to be established. The first channel is between the virtual machine and the process server. This channel collects the data from the VM and sends it to the process server which then sends the data to the master target server. If the process server and the virtual machine to be protected are on the same Azure virtual network then you don't need to use NAT settings. Otherwise specify NAT settings. View the public IP address of the process server in Azure.
  223. ![](./media/site-recovery-failback-azure-to-vmware/image28.png)
  224. 2. The second channel is between the process server and the master target server. The option to use NAT or not depends on whether you are using a VPN based connection or communicating over the internet. Don't select NAt if you're using VPN, but only if you're using an internet connection.
  225. ![](./media/site-recovery-failback-azure-to-vmware/image29.png)
  226. ![](./media/site-recovery-failback-azure-to-vmware/image30.png)
  227. 3. If you haven't deleted the on-premises virtual machines as specified and if the datastore you are failing back to still contains the old VMDK’s then you will need to ensure that the failback VM gets created in a new place. To do this select the **Advanced** settings and specify an alternate Folder to restore to in **Folder Name Settings**. Leave the other options with their default settings. Apply the folder name settings to all the servers.
  228. ![](./media/site-recovery-failback-azure-to-vmware/image31.png)
  229. 4. Run a Readiness Check to ensure that the virtual machines are ready to be protected back to on-premises.
  230. ![](./media/site-recovery-failback-azure-to-vmware/image32.png)
  231. 5. Wait for it to complete. If it's successfully on all VMs you can specify a name for the protection plan. Then click **Protect** to begin.
  232. ![](./media/site-recovery-failback-azure-to-vmware/image33.png)
  233. 6. You can monitor progress in vContinuum.
  234. ![](./media/site-recovery-failback-azure-to-vmware/image34.png)
  235. 7. After the step **Activating Protection Plan** finishes you can monitor VM protection in the Site Recovery portal.
  236. ![](./media/site-recovery-failback-azure-to-vmware/image35.png)
  237. 8. You can see the exact status clicking on the VM and monitoring its progress.
  238. ![](./media/site-recovery-failback-azure-to-vmware/image36.png)
  239. ## Prepare the failback plan
  240. You can prepare a failback plan using vContinuum so that the application
  241. can be failed back to the on-premises site at any time. These recovery plans are very similar to the recovery plans in Site Recovery.
  242. 1. Launch vContinuum and select **Manage plans** > **Recover.** You can see of list of all the plans that have been used to fail over VMs. You can use the same plans to recover.
  243. ![](./media/site-recovery-failback-azure-to-vmware/image37.png)
  244. 2. Select the protection plan and all of the VMs you want to recover in it. When you select each VM you can see more details including the target ESX server and the source VM disk. Click **Next** to begin the Recover Wizard and select the VMs you want to recover.
  245. ![](./media/site-recovery-failback-azure-to-vmware/image38.png)
  246. 3. You can recover based on multiple options but we recommend you use **Latest Tag** and select **Apply for All VMs** to ensure that the latest data from the virtual machine will be used.
  247. 4. Run the **Readiness Check.** This will check if the right parameters are configured to enable VM recovery. Click **Next** if all the checks are successful. If not check the log and resolve the errors.
  248. ![](./media/site-recovery-failback-azure-to-vmware/image39.png)
  249. 8. In **VM Configuration** ensure that the recovery settings are correctly set. You can change the VM settings if you need to.
  250. ![](./media/site-recovery-failback-azure-to-vmware/image40.png)
  251. 9. Review the list of virtual machines that will be recovered and specify a recovery order. Note that VMs are listed using the computer host name. It
  252. might be difficult to map the computer host name to the virtual machine.
  253. To map the names, go to the virtual machines **Dashboard** in Azure and check the VM host name.
  254. ![](./media/site-recovery-failback-azure-to-vmware/image41.png)
  255. 10. Specify a plan name and select **Recover later**. We recommend to recover later since the initial protection might not be complete.
  256. 11. Click on **Recover** to save the plan or trigger the recovery if you've selected to recover now and not later. You can check the recovery status to see if the plan's been saved.
  257. ![](./media/site-recovery-failback-azure-to-vmware/image42.png)
  258. ![](./media/site-recovery-failback-azure-to-vmware/image43.png)
  259. ## Recover virtual machines
  260. After the plan's been created, you can recover the virtual machines. Before you do check that the virtual machines have completed synchronization. If replication status shows OK then the protection is completed and the RPO threshold has been met. You can verify health in the VM properties.
  261. ![](./media/site-recovery-failback-azure-to-vmware/image44.png)
  262. Turn off the Azure virtual machines before you initiate the recovery. This ensures there's no split brain and that users will only access one copy of the application.
  263. 1. Start the saved plan. In vContinuum select **Monitor** the plans. This lists all the plans that have been run.
  264. ![](./media/site-recovery-failback-azure-to-vmware/image45.png)
  265. 2. Select the plan in **Recovery** and click **Start**. You can monitor recovery. After VMs have been turned on you can connect to them in vCenter.
  266. ![](./media/site-recovery-failback-azure-to-vmware/image46.png)
  267. ## Protect to Azure again after failback
  268. After failback has been completed you'll probably want to protect the virtual
  269. machines again. Do this as follows:
  270. 1. Check that the virtual machines on-premises are working and that applications are reachable.
  271. 2. In the Azure Site Recovery portal, select the virtual machines and delete them. Select to disable the protection of the virtual machines. This ensures that the VMs are no more protected.
  272. 3. In Azure delete the failed over Azure virtual machines
  273. 4. Delete the old virtual machine on vSpehere. These are the VMs that you previously failed over to Azure.
  274. 5. In the Site Recovery portal protect the VMs that recently failed over. After they're protected you can add them to a recovery plan.
  275. ## Next steps
  276. - [Read about](site-recovery-vmware-to-azure-classic.md) replicating VMware virtual machines and physical servers to Azure using the enhanced deployment.