Doing What They Say Can’t be Done
I’ve had to do this task a few times but because they were separated by a significant amount of time both the methods changed slightly and my memory of the exact steps faded. These are the new-and-improved way to convert a bare metal Windows server (I’m doing 2008 R2, but it will work with 2012 R2, etc.) into an EC2 AMI. It took me several days and multiple attempts (mostly due to the time it took to copy the 120 GB image to AWS) and some trial and error, but if you follow these steps you should have success moving your server to the cloud.
Although various commercial tools exist to perform cloud migrations I used all free tools for this physical-to-cloud migration.
Review these prerequisites for VM Import to help ensure success. This AWS document is a good reference for other necessities and steps as well. According to AWS a physical server-to-AMI conversion cannot be done, but we’ll trick them a bit by converting to a Hyper-V VM from physical, then to an AMI, finally launching an EC2 instance.
Step 1 – Prepare Your Server
Prior to migration you should do a little house keeping to minimize potential issues and decrease the overall time the migration will take. Some suggestions are first, clean up your drive(s) by removing any unnecessary files and directories, this will make the virtual disk smaller and reduce time to copy files to AWS. Next, make sure at least one NIC has DHCP enabled (one of the things that will cause your import to fail). I also took the opportunity to make sure all apps and patches were up-to-date as well. I chose not to remove my server from the AD domain at this point – only after a successful import of the server into EC2.
Step 2 – Create VHD (Virtual Hard Disk) from Physical Server
This is simple with the free Sysinternals tool Disk2vhd. Download and run it. Select the volume(s) you want to turn into a VHD and the name of the destination VHD file (by default it uses the NetBIOS name of the server). Make sure to uncheck “use Vhdx” option as AWS will only allow you to import a VHD file and not a VHDX file. It is recommended that you save the VHD file to a drive other than one you are imaging, but since I didn’t have another drive at the time I wasn’t able to do that and the conversion worked fine. The server I am working on currently is named Alymere, so you’ll see that name throughout.
 |
|
|
Step 3 – Import VHD to Hyper-V
Use Hyper-V Manager to import the VHD exported in the previous step. I had another server (at another location) which I was able to install Hyper-V on to perform these steps, but I suppose you could do this on the origin server if it’s the only one you have. Maybe I’ll try it and update later….. Start your newly imported VM to make sure it boots and works as a VM, then shut it down. One critical step is to remove any CD or DVD drives from the VM as these too will cause the EC2/AMI import to fail.
Step 4 – Export VM to VHD
Again, using Hyper-V Manager export the VM. This will create a few directories and possibly additional files, but the only one you need is the new VHD file – in my case this is Alymere.vhd (although it’s the same name as the physical to virtual VHD file it is a different file).
Step 5 – Break up the VHD
If you’ve ever tried to copy a large file over the Internet you know it can be fraught with problems. So, for multiple reasons I used 7-zip to break the file into 100MB chunks. I did it as 7z format with a compression level of “normal.” Although it took about four hours for the compression I saved about eight times that much time when uploading to AWS. My ~120GB VHD file compressed to 41GB of zipped files.
Step 6 – Copy/Upload File(s) to EBS
Since I will have to extract my hundreds of 100MB files back to the original VHD I copied them to an EBS volume on one of my existing EC2 servers over a VPN connected to my VPC using robocopy. One of the reasons for breaking the original file into many smaller ones is that if there’s a problem with the copy (as is common over the Internet) I won’t lose much progress – yes this can be done by using the /z (restart) switch with robocopy – which I would highly recommend, but I’ve had better experiencing breaking large files into smaller ones. Another reason I did this was that the office where the server resides has terrible upload speeds, so I copied the files to an external drive and had my business partner take it to another office (I’m in a different state). It still took 2-3 days to copy the files from both locations to AWS, but was considerably faster doing it the way we did – copying zipped files from two locations to EC2 simultaneously.
Step 7 – Reassemble VHD
Once the files were all copied to my EBS volume on my EC2 server I used 7-zip to extract the files to the original VHD file. As mentioned previously this whole process (zip, copy, unzip) took several days, but using the methods described I feel it was the most efficient way possible given the circumstances. If you have low upload bandwidth or huge files it may make sense to use the AWS Import/Export service (now AWS Snow Family), which I’ve used with great success previously.
Step 8 – Copy/Upload to S3
In order to use AWS’s VM import/export the VHD file(s) have to reside in S3. Some tools (like my beloved CloudBerry) cannot copy files of this size (120 GB), so I used the AWS CLI. Namely, aws s3 cp:
aws s3 cp E:TempAlymereALYMERE.VHD s3://<bucket name>/Alymere/
The AWS CLI displays copy progress, including speed.
 |
|
|
Step 9 – Import VHD to AMI
This step requires a little extra work. Follow these steps to create an AMI role and policy necessary to access S3, along with the necessary .json files tailored to your needs. With that done run the command (adapted for your use):
aws ec2 import-image --description "Alymere" --disk-containers file://C:AWSJSONcontainers.json
Depending on the size of the VM this will take from a few minutes to an hour or more. My 120GB VHD took about 90-120 minutes. Executing the export-image command will produce various output including a task ID, which can be used to check the progress of the import:
aws ec2 describe-import-image-tasks --import-task-ids import-ami-<task ID>
I ran this several times and could see it progressing.
Upon completion the message, “AWS Windows completed…” is displayed, along with the AMI ID.
Step 10 – Launch EC2 Instance
Finally, an EC2 instance can be launched from this newly created AMI.
aws ec2 run-instances --image-id ami-<task ID>
Step 11 – Post Launch
At this point I logged onto my newly created VM to verify all my applications and data were intact. Since they were I removed my “old” physical server from my domain and joined this one. Success!
Troubleshooting VM Import/Export
A variety of issues can cause problems, i.e. failure. I would suggest reading the prerequisites for VM Import and “Troubleshooting VM Import/Export” AWS pages before beginning to make sure you can avoid issues, then be able to troubleshoot if necessary.
Good luck and happy importing!