background

As customers migrate from their own virtualized data centers to UCloud, they want to be able to switch from the old VMware architecture to the public cloud. Among them:

  • The customer wants to go to the cloud without affecting the existing business;
  • Remove the overprotection equipment managed in the computer room to reduce unnecessary expenditure;
  • Reduce the pressure of resource maintenance and operation;

In addition, it is hoped that the migration process will not be too long and will not affect the work of marketing and business innovation.

First, migration evaluation

After feasibility analysis, there are at least the following challenges:

  1. Customers have a wide variety of operating systems with older versions, most of which are Windows Server versions.
  2. Business systems cannot be rebuilt because the software does not have deployment guidelines and source code, or because there are no people to redeploy.
  3. Large amount of data migration, including database and backup data.
  4. The customer cannot or does not want to rebuild the business system due to reasons such as the old business software version used by the customer and the failure to purchase authorization. For example, the customer purchased a complete set of third-party business software, such as SAP and ERP, etc.

For the above reasons, off-the-shelf tools cannot be used, because the migration tools support the mainstream operating systems (CentOS, Ubuntu) well, but the older systems cannot be used due to the lack of vendor support for the new hardware drivers.

Therefore, migration can only be done by mirroring.

Second, migration scheme

Based on the above background and migration assessment, the overall migration ideas are basically in two directions:

  1. Public transport

The preconditions are:

  1. The public network bandwidth is large enough and does not affect the existing production business;
  2. Data sensitivity is not high, allowing public network transmission;
  3. The data volume is not too large, preferably not more than 10T class;

2. Offline disk copy

For the amount of data is too large, the public network bandwidth is not large enough, because of security factors is not convenient public network transmission, is the public network online transmission can not do, can reflect the advantage of offline disk copy.

Here, U flash disk (which can be understood as AWS Snowball and Ali Lightning Cube) is used for the transmission of mirror images. The main advantages are as follows:

  1. High data security and large space: the large capacity space of RAID5 is guaranteed for the security of data.
  2. Fast transmission speed: the interface supports USB3.0, the maximum speed is 500MB/s, and the storage medium reads and writes speed is about 150MB/s.
  3. Physical server can be mounted: the physical machine in the managed area communicates with the network in the public cloud area and is connected with the internal network of the public cloud US3 service. If a large amount of data outside the computer room needs to be copied to the computer room, data transmission can be carried out in this way.

In order to simplify the steps and reduce the intermediate state waiting time, and in order to shorten the single migration process time, the asynchronous operation is adopted to reduce the waiting time caused by synchronous operation.

In this example, scheme 2, offline disk migration, is chosen to speed up migration due to large data.

III. Migration details

The migration flow chart is as follows:

First, you need to:

  • Disable the Guest system’s Windows group policy;
  • Uninstall the Guest system’s VMWare-Tool Tool;
  • Turn off antivirus software;
  • Shut down the virtual machine.

In the above process, the physical cloud server should be created in advance, the system disk and the data disk image transmission should be carried out through the U flash disk, and the U flash disk with stored data should be mounted to the physical cloud server. Meanwhile, the format conversion of the system disk image and the driver injection process should be completed in the physical cloud host.

Create a temporary transfer machine in the physical cloud host through internal API, and create a cloud disk with system disk property, take the mounted U flash disk as the local site, through QEMU-NBD, remotely mount the system disk and data disk of the U flash disk to two cloud disk (system disk and data disk) of the created medium transfer respectively.

Unload the two cloud disks that are bound to the middle server temporarily, create the cloud host through the system disk (this process needs internal API to achieve), and mount the other disk as the data disk to complete the migration of the system disk and data disk of the cloud host.

3.1 VMware environment preparation in IDC

1. The vSphere client connects to the vCenter server

Install vSphere client, remotely connect to vCenter, VMware’s management node in IDC, and transfer the corresponding cloned image to U flash disk for storage.

2. Export the image

For shutdown and offline systems, you can directly export the image in OVF or VMDK format; For the system that cannot be exported offline, mirror cloning can be carried out, and the format after cloning is VMDK.

3.2 Preparation of the relay server environment

① Install KVM virtualization environment

Install the CentOS 7 operating system and make sure that hardware virtualization is enabled. Ensure that the disk space is not less than the amount of migrated data. To install KVM virtualization, execute the following command:

# yum install qemu-kvm qemu-key-tools libvirt  qemu-img
# yum install virt-*
# modprobe kvm
# modprobe kvm_intel
# systemctl start libvirtd
# systemctl enable libvirtd.service

(2) install virt – v2v

Considering the compatibility of cloud service providers (such as IO and network acceleration, high kernel version of the system), virt-v2v conversion is required for older systems, such as Windows 2000, Windows Server 2003, Windows Server 2008, etc.

For IO acceleration, virt-v2v is used to automatically inject the VirtIO driver. Virt-v2v is used to import virtual machines from one virtual platform to another. Virt-v2v is used to convert virtual machines running on other hypervisors. This allows you to run on Red Hat Enterprise Virtualization or on KVM managed by Libvirt. Currently, virt-v2v can convert Red Hat Enterprise Linux and Windows virtual machines running on Xen, KVM, and VMware ESX/ESX(I). If needed, virt-v2v will enable a paravirtualization (VirtIO) driver on the converted virtual machine.

Virt-V2V converts virtual machines on external virtualization platforms to a running KVM platform. It can read Windows and Linux virtual machines running on VMware, Xen, Hyper-V and other hypervisor and convert them to KVM’s libvirt, OpenStack, Ovirt, Red Hat Virtualization (RHV) and other methods.

# yum install virt-v2v

Install the VirtIO driver on the host

The Virtio driver is a paravirtualized device driver for KVM virtual machines. Paravirtualized drivers improve machine performance, reduce I/O latency and increase throughput to near bare metal levels. Install VirtIO driver for Windows as follows:

# yum install libguestfs-winsupport libguestfs-tools
# wget https://fedorapeople.org/groups/virt/VirtIO-win/VirtIO-win.repo
-O /etc/yum.repos.d/VirtIO-win.repo
# yum install VirtIO-win

(4) Install NTFS-3G, used to mount U flash disk

NTFS-3G supports reading and writing NTFS partitions on Linux, FreeBSD, Mac OS X, NetBSD, Haiku and other operating systems. It supports all POSIX-compliant disk operations in addition to full file ownership and access rights. The goal is to provide trusted, feature-rich, high-performance solutions for hardware platforms and operating systems that users need to reliably interact with NTFS.

# yum install epel-release
# yum install ntfs*

⑤ Compile and install NDB

Installing NBD can be used for remote storage and backup. The NBD driver simulates a block device, such as a disk or a disk partition, on the local client, but actually provides physical support for a remote server connected over a network.

3.3 Mirror format conversion and VirtIO driver injection

Convert the disk file and inject the VirtIO driver. Execute the following command:

# export LIBGUESTFS_BACKEND=direct # virt-v2v-i VMX server2003. VMX -of qcow2-o qemu-os. Execution of the command virt-v2v-i VMX "VMX file name" -- of QCOW2 -- o QEMU -- OS "disk file storage path after conversion", the default is to convert the system disk and data disk, in order to save the conversion time, you can modify the VMX file to only convert the system disk.

3.4 Create transit system disk and data disk through API

A new cloud disk is created through the API as the system disk to open the cloud host and the data disk to import data (_ where the disk for system properties is internal API_). The two newly created cloud disks are both temporary middle dials, which are used to store the system and data of the imported image.

Specific apis may refer to: https://github.com/ucloud

3.5 Remote mount cloud disk with disk copy

In order to reduce the time-consuming process of migration, the system disk and data disk of the U flash disk are directly mounted to the newly created VM in the form of network, and then the data in the U flash disk and the cloud disk created by temporary transit are copied to the disk data in the internal network. In view of the limitations of disk IO and network bandwidth, the above scheme can save the transit process of public network transmission and object storage US3 storage image.

The specific process is as follows: mount the remote disk of QEMU-NBD, mount the data disk of U flash disk directly to cloud disk. Then uninstall cloud disk and mount it on the corresponding customer machine.

① mount the disk image of the U flash disk on the physical cloud server to the specific port of NBD

# QEMU-NBD-R-T-V-F QCOW2-P 5000 WEB-SDC. QCOW2 // # QEMU-NBD-R-T-V-F QCOW2-P 5000 WEB-SDC. QCOW2 //

Install QEMU-IMG on the transfer machine, and mount the remote data disk image to the newly created cloud hard disk.

# qemu-img convert NBD ://10.23.xx. XX :5000 /dev/vdc //

3.6 Create the cloud host and mount the data disk

For the system disk and data disk that have been synchronized, the cloud host is created for the system disk through API. For the cloud data disk, it is necessary to unload the cloud disk on the transfer machine first, and then mount it to the target cloud host that needs to be opened, so as to achieve the creation of the cloud host and the mount function of the data disk. UCloud has automated scripts and programs to do this.

Four, experience,

Through this migration, the supporting and limiting factors are confirmed as follows for your reference.

4.1 support

For VMware, this migration supports the following environments:

  1. Support vSphere, ESXI.
  2. Support system disk and data disk migration.
  3. Support operating systems RHEL 3-7, CentOS 3-7, Ubuntu 10.04, 12.04, 14.04, 16.04 and above, Windows XP-Windows 10/ Windows Server2016.

4.2 limit

  1. Host migrations created by VMware Workstation are at risk of failure.
  2. Windows 7 and Windows Server 2008 R2 require SHA-2 support certificates to be enabled.
  3. Operating system migration needs to be turned off and online hot migration is not supported.
  4. You need to uninstall your antivirus software.
  5. You need to uninstall the virtualization platform tools.

This article is from UCloud East China Architecture Center. If you have any relevant needs or business consultation, please contact us by private mail or leave a message in the comment area.