Simply moving the disk image of a virtual machine from the data center to the cloud will not work. You must make settings within the VMs and use tools to convert them. It would help if you never rushed to migrate VMs to the cloud. Appropriate configurations, settings, and tools are required. For starters, you can’t – and should never – migrate a VM from a local server to a cloud while the VM is running.
Then, the pre-migration process can be lengthy and vary depending on the underlying operating system and the preferences of the target cloud provider. It isn’t easy to detail every possible step. Still, an example of preparing a VM running Windows Server for an instance of Google Compute Engine can highlight some common steps.
Preparations In The VM Itself For GCP
A typical preparation for migrating a VM to the cloud is enabling Remote Desktop Protocol (RDP) on the VM. It allows local systems to connect to the instance after the migration. You can enable additional troubleshooting support resources, such as the bootcfg /ems command to provide troubleshooting assistance if the instance refuses to boot after migrating to the cloud. You can also add the SOS option to your boot parameters, like bootcfg/adds/so, which displays drivers as they load. This helps identify struggling drivers after the migration is complete. Consider the administrative integrity of the Windows Server VM.
Preparations In The VM Itself For AWS
Many preparations are similar when preparing a VM for an AWS Compute Instance, but AWS recommendations are more specific. For example, AWS recommends enabling RDP for Windows VMs, or Secure Shell ( SSH ) for Linux VMs, allowing RDP and SSH access through the firewall. AWS suggests setting up and securing passwords for all user accounts and disabling auto-login features for a Windows VM. AWS also suggests unnecessary uninstalling tools that might conflict with AWS resources.
For example, there are tools specific to VMware. Next, disconnect any physical or virtual drives the VM might rely on locally, such as CD-ROMs or flash drives. Otherwise, the VM will continue to search for these resources and cause errors. AWS also recommends using dynamic IP addressing via DHCP rather than static IP addressing. This allows the cloud to assign IP addresses after the migration is complete. Linux VMs must also use a boot manager – such as Grand Unified Bootloader (GRUB) or GRUB 2 – and a compatible file system, such as ext2, ext3, ext4, btrfs, JFS, or xfs.
Migration With Tools
You need to shut down the VM and export it to an appropriate image format to migrate to the cloud. If you want to transfer VMs to AWS Elastic Compute Cloud instances, you must install the EC2 command line tools on the local system that accesses the VM images. The ec2-import-instance command primarily allows you to specify the VM image name, format, desired target instance type, storage instance, and other parameters.
You can then check the import status using the ec2-describe-conversion-tasks command, which indicates the import status as active, canceled, or completed. If the import fails, you can determine the problem, fix it, and retry the public cloud import. Google Cloud Platform users can use a streaming tool like Daisy to create guest OS images for GCP, import physical or virtual disks into Google Compute Engine instances, deploy GCE environments, and perform GCE tests.
Do Not Rush
After the cloud import, the VM image will reside in a storage instance, such as Amazon Simple Storage Service ( S3 ). You can then log in to the cloud provider’s usual management console, locate and select the imported instance, and start that instance. After the instance starts, you can connect it to other components, test and verify it, and remove the imported image from storage, eliminating the cost of ongoing image storage.
Sometimes it is best to migrate piecemeal applications. You will start by migrating certain components or resources to the cloud, such as master data. Then you will systematically migrate other components or dependencies over time, such as additional databases or other peripheral software. This ensures that the overall application continues functioning properly at every step.
You can also fundamentally re-engineer your applications into a cloud-native form, such as a so-called container-based microservices architecture, and design them to operate expressly in the cloud rather than in a local data center. However, this effort takes time, and companies typically reserve cloud-first application initiatives for new projects; redesigning existing applications, although acclaimed by suppliers, remains rare.
Also Read: How UTM Parameters Work And Why They Are Useful
