ZStack 3.10.0>Tutorials>Advanced Features>V2V Migration Tutorial>V2V Migration

V2V Migration

Currently, the V2V Migration Service allows you to migrate VM instances from a VMware cloud platform or a KVM cloud platform to the current cloud.

Source Cloud Platform: VMware

By creating V2V migration jobs, you can migrate VM instances from the vCenter that you took over to the current Cloud.

Before migrations, perform data synchronization on the vCenter that you took over to manually synchronize the latest status of vCenter resources.
You can perform bulk V2V migrations for VM instances, and customize configurations of the destination VM instances to be migrated.
The supported versions of the source vCenter platform include 5.0, 5.1, 5.5, 6.0, 6.5, and 6.7. Note that the version of vCenter Server must be consistent with that of ESXi Host.
The supported systems of source vCenter VM instances include RHEL/CentOS 4.x, 5.x, 6.x, 7.x, SLES 11, 12, 15, Ubuntu 12, 14, 16, 18, and Windows 7, 2003, 2008, 2012, 2016.
The VM instances will be forced to shut down during the V2V migration process. Therefore, pay attention to the business impact.
Note: The system firstly attempts to shut down the VM instances softly. If the shutdown fails, the system will shut down the VM instances forcibly.
The type of the source primary storage is not enforced. The type of the destination primary storage can be LocalStorage, NFS, Ceph, and Shared Block.
For Windows VM instances, the Windows VirtIO driver is automatically installed during the migrations, which improves the NIC and disk efficiencies.
You can perform V2V migration for VM instances booted by UEFI. After migrations, these VM instances are also booted by UEFI.

You can perform the following operations on a V2V job:

Create a V2V job
Restart a V2V job
Delete a V2V job

Create V2V Job

In the navigation pane of the ZStack Private Cloud UI, choose Advanced Function > Migration Service > V2V Job. On the V2V Job page, click Create V2V Job. Then, the Create V2V Job page is displayed.

To create a V2V job, follow these five steps:

Configure source resources.
Set the following parameters:
- Source Platform: Select VMware.
- Name: Enter a name for the V2V job.
- Description: Optional. Enter a description for the V2V job.
- V2V Conversion Host: Specify a V2V conversion host.
  Note:
  - Before you create a V2V job, you must add a V2V conversion host to the Cloud.
  - The type of the V2V conversion host must be consistent with that of the source cloud platform.
  - The V2V conversion host is a host in the specified destination cluster. Make sure that the hardware resources are sufficient for V2V migration.
  - For more information about V2V conversion hosts, see V2V Conversion Host.
  - If you select multiple source VM instances, note that multiple V2V jobs will be created accordingly, and these V2V jobs will share the same V2V conversion host.
- Source Cluster: Select a cluster from the vCenter that you took over as the source cluster.
- Source VM: Select one or more vCenter VM instances from the source cluster as the source VM instance or VM instances. You can select up to 50 VM instances at a time.
  Note:
  - If you select more than one VM instance, corresponding V2V jobs will be created in bulk. Note that one V2V job corresponds to one source VM instance.
  - For Windows Server 2012 R2 and Windows Server 2016 VM instances, you need to manually disable the hibernation feature and shut down the VM instances before you create a V2V job.
    To disable or enable the Windows hibernation feature, run the following commands:
    
    Disable Windows hibernation: cmd-->“powercfg -h off”
    
    Enable Windows hibernation: cmd-->“powercfg -h on”
  - If one of the source VM instances has a data volume, make sure that the disk mode of the data volume is Dependent. Otherwise, the V2V job might fail.
    As shown in Figure 1.
    Figure 1. Disk Mode: Dependent
As shown in Figure 2.
Figure 2. Configure Source Resources
Configure destination resources.
Set the following parameters:
- Destination Zone: By default, the current zone is displayed.
- Destination Cluster: Select a destination cluster. After selected, the estimated CPU usage and memory usage are displayed.
  - CPU usage: includes the number of the used CPUs of the source VM instances and the total number of available CPUs in the destination cluster.
  - Memory usage: includes the used memory size of the source VM instances and the total available memory size in the destination cluster.
- Destination Primary Storage: Select a destination primary storage. After selected, the estimated storage usage is displayed.
  - Storage usage: includes the used storage of the source VM instances and the total available storage of the destination primary storage.
- Compression mode:
  - By default, this checkbox is selected, indicating that the compression mode is used. This will compress the caches of the migration data and improve the cache space utilization of the V2V conversion host.
  - If not selected, the compression mode is not used. If the destination primary storage is Ceph, we recommend that you do not use the compression mode.
As shown in Figure 3.
Figure 3. Configure Destination Resources
Configure network mapping.
This step configures the network architecture of the destination VM instances according to the source VM network architecture.
All source networks used by the source VM instances are displayed in the form of network mapping cards. Note that a network mapping card shows the correspondence between a source network and a destination network.
1. If all the chosen source VM instances have a NIC attached:
  Configure each network mapping as follows:
  - Network mapping:
    - Source network: The source vCenter network is displayed.
    - IP usage: The estimated IP usage of the source network.
    - Destination network: Select a corresponding destination network as needed. The destination network is the network attached to the specified destination cluster.
  - Use IP and MAC of source VM:
    - By default, this checkbox is not selected. In the next step, you can customize the MAC address and IP address for the destination NIC. If you do configure them, the destination NIC MAC address will be the same as the source NIC MAC address after migration, and the IP address of the destination NIC will be allocated by the system.
    - If selected, the destination NIC will use the MAC address and IP address of the source NIC in the next step. If the source NIC does not have an IP address, the IP address of the destination NIC will be allocated by the system.
  As shown in Figure 4.
  Figure 4. Configure Network Mapping | All Source VMs Have a NIC Attached
2. If a chosen VM instance does not have a NIC attached:
  Go to the next step to manually configure the destination NIC.
  As shown in Figure 5.
  Figure 5. Configure Network Mapping | A Source VM Does Not Have a NIC Attached
Configure destination VM instances.
1. If all the chosen VM instances have a NIC attached:
  Go to the next step if no further modification is needed. Parameters of the destination VM instances are configured by the system by default.
  You can also configure the destination VM instances by setting the following parameters:
  - Auto start VM after V2V migration: By default, this checkbox is selected, indicating that the destination VM instances will be automatically started after migration.
  - Destination VM Info:
    - Name: Set the name of the destination VM instance.
  - Source NIC No.: The NIC No. of the source VM instance is displayed.
  - Source NIC Info: The NIC information about the source VM instance, including the source network, MAC address, and IP address, is displayed.
  - Destination NIC Info:
    - L3 Network: Select an L3 network used by the destination VM instance.
    - MAC Address: Optional. You can manually configure the MAC address of the destination NIC. If not configured, the MAC address of the destination NIC will be the same as that of the source NIC after migration.
    - IP Address: Optional. You can manually configure the IP address of the destination NIC. If not configured, the IP address of the destination NIC will be allocated by the system.
    Note:
    
    Before you migrate a VM instance to the current Cloud, make sure that the VM instance has at least one NIC attached.
    
    You can manually configure the MAC address and IP address for the destination NIC, or let the system configure them automatically.
    
    Manual configuration: You can use the MAC address and IP address of the source NIC as the destination MAC address and IP address, respectively.
    
    Auto configuration: After migration, the MAC address of the destination NIC is the same as that of the source NIC, and the IP address of the destination NIC is allocated by the system.
  As shown in Figure 6.
  Figure 6. Configure Destination VMs | All Source VMs Have a NIC Attached
2. If a chosen VM instance does not have a NIC attached:
  If No network is displayed next to the name of the source VM instance, you must manually configure the corresponding destination NIC.
  To configure the destination NIC, set the following parameters:
  - Destination NIC Info:
    - L3 Network: Select an L3 network used by the destination VM instance.
    - MAC Address: Optional. You can manually configure the MAC address of the destination NIC. If not configured, the MAC address of the destination NIC will be allocated by the system.
    - IP Address: Optional. You can manually configure the IP address of the destination NIC. If not configured, the IP address of the destination NIC will be allocated by the system.
  As shown in Figure 7.
  Figure 7. Configure Destination VMs | A Source VM Does Not Have a NIC Attached
Confirm and submit.
Confirm the information about the V2V job. You can modify the information by clicking the Edit icon next to each step.
As shown in Figure 8.
Figure 8. Confirm and Submit

V2V Job Details Page

On the V2V Job page, click on the name of a V2V job. Then, the details page of the V2V job is displayed. On the details page, you can view the job status and job information, and the basic information about the source VM instance and destination VM instance.

As shown in Figure 9.

Restart V2V Job

You can restart a V2V job if the job fails.

Note:

If migration data caches exist, restarting the V2V job can improve the migration efficiency.
You can set the period for retaining the migration data caches. The method is as follows:
Go to Settings > Global Settings > Advanced, locate Retention time of migrating data, and click the Edit icon. The default value is 86,400 seconds (one day).

Delete V2V Job

You can delete a V2V job after it is completed.

More Information

When you migrate VM instances from the vCenter that you took over to the current Cloud, note that:

During the V2V migration process, do not power on the source vCenter VM instances that were stopped. Otherwise, the migration might fail.
During the V2V migration process, do not restart the V2V conversion host. Otherwise, the migration might fail.
After the V2V migration is completed, the number of drivers from which the destination VM instances are started will be set according to the number of source VM drivers. Currently, up to three drivers can be set.
Assume that you enabled the switch for automatically starting VMs after migration. If the physical resources in your destination cluster are insufficient, the destination VM instances will fail to start and enter the stopped state. At this time, the status of the V2V job is displayed as Succeeded.
For Windows VM instances, the Windows VirtIO driver is automatically installed during the migration process. You need to manually update the driver after migration. Note that the Windows VirtIO driver will be installed in the local directory, and you can search for it and then update it.
For Windows VM instances that have volumes, the volumes are in offline mode after migration. You need to manually change the mode to online.
For Linux and Windows VM instances that have volumes, the drive letter of the volumes might be modified after migration. You need to manually modify the drive letter according to the drive letter order of the source VM instances. We recommend that you record the drive letter order of the source VM instances before migration.
For Linux and Windows VM instances whose volumes are in SCSI mode, the volume mode can be automatically recognized during the migration process. You can set the volume mode for the destination VM instances after migration.
- For Windows VM instances, the volume mode defaults to non-VirtioSCSI after migration.
- For Linux VM instances, the volume mode defaults to VirtioSCSI after migration.
  Note:
  If the kernel version is relatively old, such as RHEL5 (kernel 2.x), the volumes cannot be in VirtioSCSI mode. You need to manually change the volume mode to non-VirtioSCSI after migration.
  
  For example, if a destination VM instance fails to start after migration, and an error "Cannot find hard disk" is reported, and the kernel version is relatively old (such as kernel 2.x), the reason may be that the old version of the Virtio driver does not support SCSI. In this case, you need to manually change the volume mode to non-VirtioSCSI. Then, the VM instance can enter the system after restart.
For Linux VM instances, if these VM instances were started in GUI mode before migration, you might need to update the display configuration of the VM instances for the first startup after migration.
For Linux VM instances that are booted by UEFI and whose system version is RHEL/CentOS 5.x, 6.x, or 7.x, you need to delete the rhgb parameter in the startup option for the VM instances to start successfully after migration.
For Linux VM instances that are booted by UEFI and whose version is CentOS 7.4 or later, the VM instances will enter the UEFI Shell if you start them after migration. To enter the operating system, run the following commands:
```
Shell> fs0: FS0:\> cd EFI FS0:\EFI\> cd centos FS0:\EFI\centos\> shimx64-centos.efi
```
If you want the VM instances to automatically enter the operating system instead of the UEFI Shell upon restart, run the vim /boot/efi/startup.nsh command to create a script and save the following content:
```
FS0: CD EFI CD centos shimx64-centos.efi
```
You can set the maximum number of V2V jobs that can run at a time. The method is as follows:
Go to Settings > Global Settings > Advanced, locate ParallelismDegree, and click the Edit icon. The default value is 10.
You can set the host allocator strategy for starting the destination VM instances after migration. The method is as follows:
Go to Settings > Global Settings > Advanced, locate HostAllocatorStrategy, and click the Edit icon. The default option is Host with min. running VMs.

The following table lists the migration status of a V2V job.

Migration Status	Description
Succeeded	The VM instances are successfully migrated from vCenter to the Cloud.
Failed	The VM instances failed to be migrated from vCenter to the Cloud.
Migrating	The VM instances are being migrated from vCenter to the Cloud. The migration process contains the following three phases: Data conversion: Converts the file format of vCenter VM instances and saves it to the cache path of the V2V conversion host. Data download: Downloads the VM files from the cache path of the V2V conversion host to the destination primary storage. Resource configuration: Creates and configures corresponding compute, storage, and network resources in the destination Cloud.
Canceled	The V2V job of migrating VM instances from vCenter to the Cloud is cancelled.

Source Cloud Platform: KVM

By creating V2V migration jobs, you can migrate VM instances from a KVM cloud platform to the current cloud.

You can perform bulk V2V migrations for VM instances, and customize configurations of the destination VM instances to be migrated.
You can migrate the VM instances that are running or paused. Do not power off the VM instances that need to be migrated.
You can perform V2V migrations for VM instances booted by UEFI. After migrations, these VM instances are also booted by UEFI.
The type of the source primary storage is not enforced. The type of the destination primary storage can be LocalStorage, NFS, Ceph, and Shared Block.
For different types of source primary storage or destination primary storage, the libvirt version and QEMU version must meet the following requirements:
- If either the source primary or destination primary storage is Ceph, use libvirt 1.2.16 and QEMU 1.1 or their later versions.
- If neither the source primary storage nor destination primary storage is Ceph, use libvirt 1.2.9 and QEMU 1.1 or their later versions.

You can perform the following operations on a V2V job:

Create a V2V job
Restart a V2V job
Delete a V2V job

Create V2V Job

In the navigation pane of the ZStack Private Cloud UI, choose Advanced Function > Migration Service > V2V Job. On the V2V Job page, click Create V2V Job. Then, the Create V2V Job page is displayed.

To create a V2V job, follow these five steps:

Configure source resources.
Set the following parameters:
- Source Platform: Select KVM.
- Name: Enter a name for the V2V job.
- Description: Optional. Enter a description for the V2V job.
- V2V Conversion Host: Specify a V2V conversion host.
  Note:
  - Before you create a V2V job, you must add a V2V conversion host to the Cloud.
  - The type of the V2V conversion host must be consistent with that of the source cloud platform.
  - The V2V conversion host is a host in the specified destination cluster. Make sure that the hardware resources are sufficient for V2V migration.
  - For more information about V2V conversion hosts, see V2V Conversion Host.
  - If you select multiple source VM instances, note that multiple V2V jobs will be created accordingly, and these V2V jobs will share the same V2V conversion host.
- Configure Source Platform:
  - Source Host IP: Enter the IP address of the source host.
  - Source Host SSH Port: Set the SSH port of the source host. Default port: 22.
  - SSH User Name: The default user name is root. You can also enter a normal user name.
  - Password Type:
    - If you select Password, set the following parameters:
      
      SSH Password: Enter the corresponding SSH password. You can log in to the source host through the SSH password authentication.
    - If you select Key, set the following parameters:
      
      PrivKey: Enter the corresponding SSH private key. You can log in to the source host through the SSH private key authentication.
      Note: Before you select this option, you need to create an SSH private key for the source host in advance.
  - Configure virsh:
    - By default, this checkbox is not selected, indicating that the virtual resources of the source host are not remotely accessed through virsh.
    - If selected, you need to enter the SASL Username and SASL Password when the remote libvirtd requires Simple Authentication and Security Layer (SASL) authentication. You can securely connect to the remote libvirtd only after passing the verification.
      
      SASL Username: Enter the corresponding SASL username.
      
      SASL Password: Enter the corresponding SASL password.
- Select Source VM:
  - Get VM information: Obtain information about the running or paused VM instances that are available for migration.
  - Source VM: Select one or more KVM VM instances from the source host as the source VM instance or VM instances. You can select up to 50 VM instances at a time.
    Note:
    
    Do not power off the VM instances to be migrated.
    
    If you select more than one VM instance, corresponding V2V jobs will be created accordingly in bulk. Note that one V2V job corresponds to one source VM instance.
  - Pause running VMs:
    - By default, this checkbox is not selected, indicating that the VM instances continue to run during the migration. This ensures the business continuity of the source VM instances.
    - If selected, the source VM instances will be paused when the migration starts, and the data written to the disk at that time will be migrated. After the migration is completed, you need to manually start the paused source VM instances.
    Note: For VM instances with high I/O, we recommend that you pause them before migration to ensure the data integrity.
As shown in Figure 1.
Figure 1. Configure Source Resources
Configure destination resources.
Set the following parameters:
- Destination Zone: By default, the current zone is displayed.
- Destination Cluster: Select a destination cluster. After selected, the available CPUs and memory in the destination cluster are displayed.
  - Available CPU: the total number of available CPUs in the destination cluster.
  - Available memory: the total available memory in the destination cluster.
- Destination Primary Storage: Select a destination primary storage. After selected, the available storage of the primary storage is displayed.
  - Available storage: the total available storage of the destination primary storage.
- Compression mode:
  - By default, this checkbox is selected, indicating that the compression mode is used. This will compress the caches of the migration data and improve the cache space utilization of the V2V conversion host.
  - If not selected, the compression mode is not used. If the destination primary storage is Ceph, we recommend that you do not use the compression mode.
As shown in Figure 2.
Figure 2. Configure Destination Resources
Configure network mapping.
This step configures the network architecture of the destination VM instances according to the source VM network architecture.
All source networks used by the source VM instances are displayed in the form of network mapping cards. Note that a network mapping card shows the correspondence between a source network and a destination network.
1. If all the chosen source VM instances have a NIC attached:
  Configure each network mapping as follows:
  - Network mapping:
    - Source NIC: The information about the source NIC is displayed.
    - IP usage: The estimated IP usage of the source NIC.
    - Destination network: Select a corresponding destination network as needed. The destination network is the network attached to the specified destination cluster.
2. If a chosen VM instance does not have a NIC attached:
  Go to the next step to manually configure the destination NIC.
As shown in Figure 3.
Figure 3. Configure Network Mapping
Configure destination VM instances.
1. If all the chosen VM instances have a NIC attached:
  Configure the destination VM instances by setting the following parameters:
  - Auto start VM after V2V migration: By default, this checkbox is selected, indicating that the destination VM instances will be automatically started after migration.
  - Destination VM Info:
    - Name: Set the name of the destination VM instance.
    - CPU Core Count: Set the number of CPU cores for the destination VM instance.
    - Memory: Set the memory capacity for the destination VM instance.
    - Platform: Select an operating system type for the destination VM instance.
  - Destination Data Volume Info:
    - Root Volume Info: Set a display name for the root volume of the destination VM instance.
    - Size (Root Volume): The root volume capacity of the destination VM instance is displayed.
    - Data Volume Info: Set a display name for the data volume of the destination VM instance.
    - Size (Data Volume): The data volume capacity of the destination VM instance is displayed.
    Note:
    
    By default, the root volume of a source VM instance is migrated.
    
    If a source VM instance has multiple data volumes attached, you can select one or more data volume to migrate.
    
    You can change the display name of a data volume migrated to the current cloud. However, you cannot change its real name that is used for distinguishing itself from others.
  - Destination NIC Info:
    - L3 Network: Select an L3 network used by the destination VM instance.
    - VM NIC Setting:
      
      Fixed IP: Optional. You can manually configure the IP address of the destination NIC. If not configured, the IP address of the destination NIC will be allocated by the system.
      
      MAC Address: Optional. You can manually configure the MAC address of the destination NIC. If not configured, the MAC address of the destination NIC will be the same as that of the source NIC after migration.
    Note:
    
    Before you migrate a VM instance to the current cloud, make sure that the VM instance has at least one NIC attached.
    
    You can manually configure the MAC address and IP address for the destination NIC, or let the system to configure them automatically.
    
    Manual configuration: You can use the MAC address and IP address of the source NIC as the destination MAC address and IP address, respectively.
    
    Auto configuration: After migration, the MAC address of the destination NIC is the same as that of the source NIC, and the IP address of the destination NIC is allocated by the system.
2. If a chosen VM instance does not have a NIC attached:
  If No network is displayed next to the name of the source VM instance, you must manually configure the corresponding destination NIC.
  To configure the destination NIC, set the following parameters:
  - Destination NIC Info:
    - L3 Network: Select an L3 network used by the destination VM instance.
    - VM NIC Setting:
      
      Fixed IP: Optional. You can manually configure the IP address of the destination NIC. If not configured, the IP address of the destination NIC will be allocated by the system.
      
      MAC Address: Optional. You can manually configure the MAC address of the destination NIC. If not configured, the MAC address of the destination NIC will be allocated by the system.
As shown in Figure 4.
Figure 4. Configure Destination VMs
Confirm and submit.
Confirm the information about the V2V job. You can modify the information by clicking the Edit icon next to each step.
As shown in Figure 5.
Figure 5. Confirm and Submit

View V2V Job Details

On the V2V Job page, click on the name of a V2V job. Then, the details page of the V2V job is displayed. On the details page, you can view the job status and information, and the basic information about the source VM instance and destination VM instance.

As shown in Figure 6.

Restart V2V Job

You can restart a V2V job if the job fails.

Note:

If migration data caches exist, restarting the V2V job can improve the migration efficiency.
You can set the period for retaining the migration data caches. The method is as follows:
Go to Settings > Global Settings > Advanced, locate Retention time of migrating data, and click the Edit icon. The default value is 86,400 seconds (one day).

Delete V2V Job

You can delete a V2V job after it is completed.

More Information

When you migrate VM instances from a KVM cloud platform to the current cloud, note that:

For VM instances with high I/O, we recommend that you pause them before migration to ensure the data integrity. When you perform V2V migrations for VM instances that undergoing high I/O operations, a portion of data in the memory might not be saved to hard disks. In this case, this portion of data might be lost after V2V migration.
During the V2V migration process, do not power the source VM instances.
During the V2V migration process, do not restart the V2V conversion host. Otherwise, the migration might fail.
After the V2V migration is completed, you need to manually start the source VM instances that were paused.
Assume that you enabled the switch for automatically starting VMs after migration. If the physical resources in your destination cluster are insufficient, the destination VM instances will fail to start and enter the Stopped state. At this time, the status of the V2v job is displayed as Succeeded.
You can set the maximum number of V2V jobs that can run at a time. The method is as follows:
Go to Settings > Global Settings > Advanced, locate ParallelismDegree, and click the Edit icon. The default value is 10.
You can set the host allocator strategy for starting the destination VM instances after migration. The method is as follows:
Go to Settings > Global Settings > Advanced, locate HostAllocatorStrategy, and click the Edit icon. The default option is Host with min. running VMs.

The following table lists the migration status of a V2V job.

Migration Status	Description
Succeeded	The VM instances are successfully migrated from a KVM could platform to the Cloud.
Failed	The VM instances failed to be migrated from a KVM could platform to the Cloud.
Migrating	The VM instances are being migrated from a KVM could platform to the Cloud. The migration process contains the following three phases: Data conversion: Converts the file format of KVM VM instances and saves it to the cache path of the V2V conversion host. Data download: Downloads the VM files from the cache path of the V2V conversion host to the destination primary storage. Resource configuration: Creates and configures corresponding compute, storage, and network resources in the destination Cloud.
Canceled	The V2V job of migrating VM instances from a KVM could platform to the Cloud is canceled.

Next Chapter:V2V Conversion Host

V2V Migration

Source Cloud Platform: VMware

Create V2V Job

V2V Job Details Page

Restart V2V Job

Delete V2V Job

More Information

Source Cloud Platform: KVM

Create V2V Job

View V2V Job Details

Restart V2V Job

Delete V2V Job

More Information

Products

Solutions

Help & Support

Contact Us