Understanding VM Replication

The replication plugin in Oracle Cloud Migrations manages the replication of source assets snapshots from the source environment to Oracle Cloud Infrastructure.

The replication plugin takes snapshots from volumes of source VM and copies them into the replication bucket.

About Replication Bucket

The replication bucket is used temporarily to facilitate the transfer of VMware snapshots to the target OCI tenancy. Once snapshot data is written to a block volume, it is removed from the replication bucket.

Create a private bucket in a replication compartment, which you specify during migration for replication location. You can choose to specify a user-specified bucket name instead of system-generated bucket names. User-specified bucket names can have letters (upper or lower case), numbers, hyphens, underscores, and periods. For more information about managing buckets for snapshot operations, see Object Storage Buckets.

For example:

Create a bucket for a compartment in a target region that you're migrating to.

For VMware migration, use the following policies relevant to the bucket,

Allow dynamic-group HydrationAgentDynamicGroup to read objects in compartment <migration_compartment_name>

Allow dynamic-group HydrationAgentDynamicGroup to {OCM_HYDRATION_AGENT_TASK_INSPECT, OCM_HYDRATION_AGENT_TASK_UPDATE, OCM_HYDRATION_AGENT_REPORT_STATUS} in compartment <migration_compartment_name>

For AWS migration, use the following policies relevant to the bucket,

Allow dynamic-group HydrationAgentDynamicGroup to manage objects in compartment <migration_compartment_name>

Allow dynamic-group HydrationAgentDynamicGroup to {OCM_HYDRATION_AGENT_TASK_INSPECT, OCM_HYDRATION_AGENT_TASK_UPDATE, OCM_HYDRATION_AGENT_REPORT_STATUS} in compartment <migration_compartment_name>

For more information about Oracle Cloud Migrations policies, see Oracle Cloud Migrations Service Policies.

About Hydration Agent

The hydration agent is a Compute instance that starts at the replication location, which you specify during creating migration project.

The hydration agent aims at block copying the snapshots of assets taken by the replication plugin (copied directly from EBS volume in case of EC2 assets) into the generated block volumes at Oracle Cloud Infrastructure. The hydration agent instances start automatically to load balance the replication process based on the object pool logic. The hydration agent instances are created based on algorithms for the approved shapes and images. Each hydration agent instance creates one VCN, one subnet, and associated resources (VCN route table). To know about the maximum number set for the VCN, subnet, and associated resources, see Networking Limits in Service Limits. You can submit a request to increase your service limits from within the Console. To increase the service limit, see Requesting a Service Limit Increase.

The approved shapes algorithm chooses one of the shapes available in an availability domain and compartment. The algorithm prefers shapes with minimum CPU number and minimal cost. For more information about the VM shapes of standard series, see Virtual Machine (VM) Shapes.

The algorithm for approved images starts the hydration agent instance with one of the approved images such as, Oracle-Linux-7.9 OS that's available. With the new image deployments, the algorithm gets updated.

In case of AWS, the Hydration agent launched by OCI migration in your tenancy utilizes the EBS Direct API to copy data blocks of a full snapshot, or only changed blocks between two snapshots, and writes it directly to the OCI block volumes.

Limits for Hydration Agent

Ensure that you reserve sufficient limits for the hydration agent instances. Only administrators can increase the hydration agent limits.

Ensure you have adequate limits in the target region for the VM.Standard.E4.Flex (standard-e4-core-count, standard-e4-memory-count) shape. We recommend that you reserve 10 CPU and 160 GB memory of the available capacity for the hydration agents. Also, ensure to consider the shape limit requirements for the VMs to be migrated.

If Standard.E4 shape isn't available, we recommend that you reserve appropriate resources for the approved shapes.

About Incremental Transfers

The incremental transfers require you to enable Changed Block Tracking (CBT) at the VMware VM level.

Incremental Transfers in VMware

The replication plugin automatically performs an incremental update when a common VM snapshot to work from, exists and you enable CBT for the VM. For enabling CBT, search for the Changed Block Tracking (CBT) on virtual machines article.

Required Virtual Machine Configurations

Following VMware virtual machine (VM) parameter values that you must set up before migrating the assets:


Parameter	Value	Setup steps
`disk.EnableUUID`	`True`	By default the `disk.EnableUUID` parameter is enabled. If not, then follow the given steps to enable the parameter: Shut down the VM. Right-click on the VM and click Edit Settings. Select the Options tab. Select General under the Advanced section. Select Configuration Parameters on the right-side menu. Check if the parameter, `disk.EnableUUID` exists and the value is set to `TRUE`. If not, then set the value to `True`. If the parameter does not exist, then select Add Row and add it. Start the VM.
`ctkEnabled`	`True`	By default, Changed Block Tracking (CBT) is not enabled on VMware VMs. To enable CBT, see CBT on Virtual Machines .

Incremental Transfers in AWS

For AWS EC2 migration, incremental transfer is achieved automatically by only replicating the changed blocks in between the volume snapshots through related AWS API endpoints providing that functionality. There is nothing to be configured for AWS migration.

Working with Encrypted EBS Volumes

One of the features of the Oracle Cloud Infrastructure Block Volume service is that volumes are always encrypted at-rest. In contrast, Amazon Elastic Block Store (Amazon EBS) has the ability to have encrypted and non-encrypted volumes. When an EBS volume is encrypted, by default, any snapshots that are created of that volume are also encrypted using the same AWS KMS key. Oracle Cloud Migrations seamlessly supports replication of both encrypted and non-encrypted EBS volumes but does require access to any AWS KMS keys used for encrypted volumes. If a migration project replication includes an EC2 instance with attached EBS volumes that are encrypted, but the user specified for replication doesn't have access to the appropriate AWS KMS key, EBS read errors occur and cause the replication job to fail. Proper AWS KMS key access follows the normal EBS process of decrypting the encrypted snapshot during the read and transfer process.

Providing Access to AWS KMS Keys

To ensure successful replication of encrypted EBS volumes, the replication credentials configured in an AWS asset source must have access to use the AWS KMS key used to encrypt the volume. AWS KMS includes a default key policy that allows users to use a KMS key for all cryptographic operations. The only cryptographic operation used by OCM during the process of replicating EBS volumes from a snapshot is Decrypt. The replication user specified in the asset source can be added as a key user directly to the key in the AWS KMS service.

Boot Volume Modifications for Migration

Migrating a virtual machine to Oracle Cloud Infrastructure (OCI) Compute requires some OS level (boot volume) modifications to ensure that the migrated instance boots up successfully on the OCI Compute hypervisor.

The Oracle Cloud Migrations service automatically applies the required configuration changes on the boot volume of Linux virtual machines. These changes include installation of virtio kernel modules when not present, storage attachment updates, and kernel parameters for serial console access. No configuration changes are made automatically to Windows virtual machines.

Boot Volume Modification for Linux

The following table shows the boot volume configurations that Oracle Cloud Migrations automatically modifies for all the supported operating systems. If you're using an unsupported Linux OS, see the table includes steps to manually apply the required configuration changes before replicating the boot volume to OCI.

Note

For information about the supported Linux OS, see Supported Source VM Guest Operating Systems.

Automatic Modifications for Linux


Configuration change	Description	Steps to manually apply a configuration
Enable serial console	We recommend you to enable serial console for troubleshooting VM instances after migration by using Oracle Cloud Console.	Apply the following configuration changes to the boot configuration: To `/etc/securetty`, add `ttyS0` if the path exists. Modify the following options in the GRUB configuration of your Linux VM: `console=tty1` `console=ttyS0,115200` Remove the following options in the GRUB configuration for your Linux VM: `rhgb` `quiet` For more information, see Enabling Serial Console Access for Imported Linux Images.
Install virtio drivers Only paravirtualized mode for Linux-based operating systems is supported now. Linux-based operating systems with kernel versions 3.4 or later support paravirtualized drivers.	Ensure that virtio kernel drivers are present in the kernel.	Apply the following configuration changes, as required: To verify whether virtio kernel drivers are included in the kernel, run the following command. `lsinitrd \| grep "/virtio_net` To install the virtio kernel drivers when not present, run the following command. `dracut -f -add qemu INITRAM_FS_FILE KERNEL_VERSION`
Update `/etc/fstab`	We recommend you to refer devices using UUID or Logical Volume Manager (LVM) name in `/etc/fstab`. If you refer devices using the file name, these devices can't be accessed after migration and the instance fails to boot up.	Apply the following configuration changes: Mark all mount points that references to a device file as, nofail. To mark, edit the `/etc/fstab` file so that it appears as follows. `/dev/sdb1 /data01 ext4 defaults,nofail 0 0`

Additional Modifications for Linux

The following modifications may also need to be performed during the migration process.


Tasks	Description
Remove udev rule	Remove any udev rules based on MAC address.
Enable SSH access to a VM	Ensure that you enable SSH and set the SSHD service to start automatically on reboot. Ensure that you don't block the incoming SSH connection requests by firewalls.
Configure network	Update network interfaces to receive IP addresses based on DHCP. Ensure that you don't use any hard-coded MAC addresses, static IP addresses, and DNS settings on the VM.
Install Oracle Cloud Agent	Install and enable Oracle Cloud Agent. See Oracle Cloud Agent.
Install OS Management	Install and enable OS Management. See Oracle Cloud Agent.
Remove other cloud agents	We recommend you to disable or remove other cloud management agents.
Configure NTP service	We recommend you to update the OCI NTP service configuration after migrating your VM instances to OCI. See Configuring the Oracle Cloud Infrastructure NTP Service for an Instance.

Boot Volume Modification for Windows

Oracle Cloud Migrations only supports launching of migrated Windows instances with paravirtualized launch options. The Oracle virtio drivers for Windows need to be installed prior to attempting to launch a migrated Windows instance. The operating system fails to find a boot device if the drivers are not installed. For information on how to install the Oracle virtIO driver for Windows, see Importing Custom Windows Images.

Note

For information about the supported Windows operating systems, see Supported Source VM Guest Operating Systems.

Additional Modifications for Windows