Migrating a Physical Machine or Virtual Machine to an everRun 7.x System

1. Download the P2V client ISO file from the Downloads page at http://www.stratus.com/go/support/everrun.

   1. On the Downloads page, click everRun (if it is not already displayed) and then select the appropriate version.
   2. Scroll down to Drivers and Tools and then continue scrolling to everRun P2V Client for Virtual or Physical Machine Migration.
   3. Select the P2V Client (virt-p2v) file.

2. If you want to verify the integrity of the ISO image, also download the associated fciv checksum file, and then download the Microsoft File Checksum Integrity Verifier (FCIV) executable file from the Microsoft Support web site. Save both files to the directory that contains the downloaded ISO file.

   Open a command prompt. From the directory containing the ISO, executable, and verification files, type a command similar to the following to verify the ISO image:

   fciv -v -xml virt-p2v-n.n.n-n.nnnnnnnn.n.el6.centos.xml

   If the command succeeds (that is, it returns the message All files verified successfully), go to the next step. If the command fails, repeat the download.

3. Burn the P2V client ISO file to a CD-ROM that you will use to boot the physical machine.
   
4. Insert the P2V client CD into the CD/DVD drive of the source PM.
5. Shut down the PM in preparation to boot the P2V client.

1. Download the P2V client ISO file from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun. Ensure that you download the version of the P2V client that matches the version of the everRun system to which you are migrating the VM.

2. If you want to verify the integrity of the ISO image, also download the associated fciv checksum file, and then download the Microsoft File Checksum Integrity Verifier (FCIV) executable file from the Microsoft Support web site. Save both files to the directory that contains the downloaded ISO file.

   Open a command prompt. From the directory containing the ISO, executable, and verification files, type a command similar to the following to verify the ISO image:

   fciv -v -xml virt-p2v-n.n.n-n.nnnnnnnn.n.el6.centos.xml

   If the command succeeds (that is, it returns the message All files verified successfully), go to the next step. If the command fails, repeat the download.

3. Insert or connect the P2V client ISO file to the source VM and set the virtual CD drive as the boot device in the associated hypervisor.
4. Shut down the VM in preparation to boot the P2V client.

1. Power on the source PM or VM to boot the P2V client. After a minute or so, the virt-p2v window is displayed.
2. The P2V client automatically obtains network settings through DHCP. Static settings are unnecessary for the migration process, but you can optionally click Configure network to specify the settings. (If necessary, configure the network settings of the target VM later on the everRun system.)
3. Enter the connection settings for the Conversion server (the everRun system). Enter the hostname or IP address of the system and the Password for the root account. (You must use the root account of the everRun host operating system, as described in Accessing the Host Operating System.)

4. Click Test connection. If the P2V client connects to the everRun system, click Next to continue. The Target properties page is displayed.

   If the P2V client cannot connect, verify the connection settings and try to connect again.

5. Enter the Name for the target VM that will be displayed in the everRun Availability Console. (The name must be different from any existing VMs on the everRun system.)
6. The # vCPUs and Memory(MB) values are automatically detected and completed, but optionally modify them if you want the VM on the everRun system to have more CPUs or memory than the source PM or VM.
7. Specify the Virt-v2v output options for the target VM, as follows:
   1. Next to Output to, select everrunha (High Availability) or everrunft (Fault Tolerant) operation. (For information about these levels of protection, see Creating a New Virtual Machine and Modes of Operation.)
   2. Next to Output format, select the disk image format, raw or qcow2. (The qcow2 format supports snapshots.)
8. If you want to save debugging messages from the migration process, optionally select the Enable server-side debugging check box. (The debugging messages are included if you generate a diagnostic file for your authorized Stratus service representative, as described in Creating a Diagnostic File.)

9. Select which Fixed hard disks (volumes) to include in the migration by activating the check box next to each device.

   You must select at least one volume, including the boot volume. (Because the P2V client is a Linux-based utility, all devices are listed by Linux device names, where sda or vda represents the boot volume.)

   If the target everRun system has more than one storage group, you can also select the storage group in which to create each volume. Double-click the volume entry to open the Choose Storage Group panel. Ensure that you select a Storage Group that supports the sector size of the volume you are importing (see Planning Virtual Machine Storage) and select the Sector Size that matches the source volume (the P2V client cannot convert the sector size of a volume). Note that the boot volume must have a sector size of 512 B. You can select the sector size, either 4K or 512B, only for data disks.

10. Select which Network Interfaces to include in the migration by activating the check box next to each device.

    If the target everRun system has more than one shared network, you can also select the shared network to connect with each network interface. Double-click the network interface to open the Choose Shared Network panel, select the shared network, and click OK.

11. When you are ready to migrate the PM or VM to the everRun system, click Start conversion. (If you need to cancel the migration for any reason, see Troubleshooting below.)
12. When the migration is complete, the P2V client displays a success message. If applicable, you can eject the CD or virtual CD and click Power Off to shut down the source PM or VM.

1. Open the Virtual Machines page (see The Virtual Machines Page) in the everRun Availability Console.

2. Select the new VM in the top pane and click Config to open the Reprovision Virtual Machine wizard, as described in Reprovisioning Virtual Machine Resources. Use the wizard to configure the desired vCPUs, memory, storage, and network settings for the VM:

   • If your source PM or VM had more than one network interface, configure the additional network interfaces that were not included in the migration process.
   • If you will continue running the source PM or VM, ensure that the MAC address for each network interface in the new VM is different from the source PM or VM.

   Click Finish on the last wizard page to implement the changes.

3. Click Start to boot the new VM.
4. Click Console to open the console of the VM and log on to the guest operating system. (For information about using the console, see Opening a Virtual Machine Console Session.)

5. For Windows-based VMs only, update the VirtIO drivers to the latest supported versions, as described in Updating the VirtIO Drivers (Windows-based VMs). (The correct VirtIO drivers are already present in Linux-based VMs.)

   Note: After updating the drivers, you may need to restart the guest operating system.

6. Disable any guest operating system services that are unnecessary for operation on the everRun system:

   • If you migrated from a PM source, disable any services that interact directly with hardware. Examples include:
     • Dell OpenManage (OMSA)
     • HP Insight Manager
     • Diskeeper
   • If you migrated from a VM source, disable any services associated with other hypervisors. Examples include:
     • VMware Tools
     • Hyper-V Tools
     • Citrix Tools for Virtual Machines

   After disabling these services, restart the guest operating system to implement your changes.

7. If necessary, update the network configuration settings in the guest operating system and restart it to enable the settings.
8. Verify that you have configured your guest operating system with the additional Windows- or Linux-based system settings described in:
• Configuring Windows-based Virtual Machines
• Configuring Linux-based Virtual Machines

After you verify that the new VM is functioning properly, the migration process is complete; however, the everRun system may continue to synchronize data between PMs to enable High Availability (HA) or Fault Tolerant (FT) operation.

If necessary, use the following information to resolve problems with the migration process.

To cancel the migration process

Power down the source PM or VM running the P2V client.

To clean up after a canceled or failed migration

Open the everRun Availability Console and remove any migrated volumes associated with the source PM or VM. If you want to restart the migration process, reboot the P2V client on the source PM or VM.

To recover from a failed migration

If the migration process fails, an error message is displayed in the P2V client on the source PM or VM. Another message may be displayed on the everRun system. Use these messages to determine the problem.

If the migration continues to fail, and the option is available, enable server-side debugging. After the migration, generate a diagnostic file to send to your authorized Stratus service representative, as described in Creating a Diagnostic File. The diagnostic file includes any server-side debugging messages from the migration process.

To recover from a migration that fails with the error message, Failed to mount '/dev/sda1: Operation not permitted

For Windows-based VMs, if the migration process fails with the following error message, it may indicate that fast startup mode is enabled:

Failed to mount '/dev/sda1': Operation not permitted
The NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting), or mount the volume read-only with the 'ro' mount option.

To resolve the issue, log on to the guest operating system of the source VM, disable fast startup mode, and shut down the operating system. Then, restart the migration process.

To recover when a newly migrated Linux-based VM is stuck in the "booting" state

A Linux-based VM may fail to exit the booting state in everRun Availability Console if the VM's network is offline.

During the migration process, the P2V client attempts to set a new MAC address for each network interface to prevent conflicts with the original VM. Some Linux-based operating systems detect a new MAC address and automatically create a new network interface for it while still retaining the original interface. The guest operating system boots, but the network may remain offline until you manually configure the network settings.

To correct the problem, open the VM console, log on to the guest operating system, and update the network startup scripts. Ensure that you retain only one entry for each network interface, and that each interface uses a unique MAC address and correct network settings for your environment.

To recover missing data volumes in the VM on the everRun system

If your data volumes do not appear in the VM on the everRun system after the import, you may need to manually restore the volumes, as follows:

• Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the volumes on the Volumes page.
• For Windows-based VMs, use Disk Management to bring data volumes online.
• For Linux-based VMs, edit the /etc/fstab file to reflect the new device names for the storage devices, from Avance (/dev/xvda through /dev/xvdh) to everRun (/dev/vda through /dev/vdh). Device names also may have shifted, for example, if volumes were not included in the import.

To recover missing network devices in the VM on the everRun system

If your network devices do not appear in the VM on the everRun system after the import , you may need to manually restore them, as follows:

• Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the networks on the Networks page.
• For Linux-based VMs, reconfigure the network startup script to reflect the new device names for the network interfaces.