Importing a Virtual Machine into Amazon EC2 (Part 5)

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article in this series, I talked about some of the things that you will need to do in order to import a virtual machine into Amazon EC2. Most of the preparation steps that I discussed were general purpose in nature, but I did talk about some preparation steps that were specific to the Linux operating system. In this article, I want to continue the discussion by talking about how you can get your Windows virtual machines ready for the migration process.

Before You Begin

Before you begin preparing your virtual machines for a migration, you absolutely must back up the virtual machines that you will be migrating. I cannot stress the importance of this highly enough.

If you are currently running Hyper-V in your data center then you have probably performed a live migration before. If you’re running VMware then you are probably used to using the vMotion feature. In either case, there is no real penalty for a migration that goes bad. The worst thing thet can usually happen is that the migration fails, and the virtual machine is left running on its original host. This simply is not the case when you migrate a Windows virtual machine to the Amazon cloud.

Before you even begin the Amazon migration process, your local copy of the virtual machine is destroyed. Let me say that again. The prep work that you must do to prepare for a migration to the Amazon cloud will destroy the virtual machine that you are going to be migrating. Let me explain.

Before a virtual machine can be migrated to the Amazon cloud, it has to be randomized. Windows virtual machines contain a number of items that are unique to that specific virtual machine. This includes things like the IP address, the computer name, and some of the identifiers that the operating system uses. Before you will be able to migrate the virtual machine to the cloud, you will have to use the SYSPREP utility to strip away anything that uniquely identifies the virtual machine. Upon doing so, most of the virtual hard disk contents are left intact, but the operating system is for all practical purposes destroyed.

If you boot a recently Sysprepped machine, you are taken into Windows Setup. The setup process asks you a few basic questions and then deploys the Windows operating system. This process returns Windows to a functional state, but there is a good chance that it will break any applications that were installed on the machine. That’s why it is so important to create a backup before you get started with the migration preparations.

Getting Started

In the previous section, I explained that if you boot a virtual machine that has recently been Sysprepped, Windows setup will run and you will see the usual prompts that you would normally see when installing Windows from scratch. The problem with this is that we are not installing Windows from scratch. We’re trying to migrate a Windows virtual machine off of a local hypervisor and onto a cloud hypervisor. There is no getting around the need to SYSPREP the virtual machine. Likewise, there is no getting around running Windows Setup after the virtual machine has been moved to its new location. However, because the virtual machine is going to be running in the public cloud, the Setup prompts need to be answered in a specific way.

For many years Microsoft has acknowledged the need for automated deployments. The primary way in which Microsoft accomplishes this is through the use of an answer file. An answer file essentially provides answers to the Setup prompts so that the Windows setup process can complete on its own, without manual intervention. It should therefore come as no surprise that one of the steps in the preparation process is to create an answer file. Here is the text that Amazon provides for the answer file:

<?xml version=’1.0′ encoding=’UTF-8′?>

<unattend xmlns:wcm=’http://schemas.microsoft.com/WMIConfig/2002/State’ xmlns=’urn:schemas-microsoft-com:unattend’>

<settings pass=’oobeSystem’>

<component versionScope=’nonSxS’ processorArchitecture=’x86 or amd64′ name=’Microsoft-Windows-International-Core’ publicKeyToken=’31bf3856ad364e35′ language=’neutral’>

<InputLocale>en-US</InputLocale>

<SystemLocale>en-US</SystemLocale>

<UILanguage>en-US</UILanguage>

<UserLocale>en-US</UserLocale>

</component>

<component versionScope=’nonSxS’ processorArchitecture=’x86 or amd64′ name=’Microsoft-Windows-Shell-Setup’ publicKeyToken=’31bf3856ad364e35′ language=’neutral’>

<OOBE>

<HideEULAPage>true</HideEULAPage>

<SkipMachineOOBE>true</SkipMachineOOBE>

<SkipUserOOBE>true</SkipUserOOBE>

</OOBE>

</component>

</settings>

</unattend>

You will need to copy this block of code into a text file using Notepad or any other text editor. There are two places in the block of code above where you will see the phrase ‘x86 or amd64’. You will need to set the processor architecture to either X86 or to X64 in both of these locations. Upon doing so, you will need to save the file to the C:\Windows\Panther folder. The file must be named unattend.xml. If you use any other file name or location then the answer file will be ignored.

Once the answer file is in place, open an elevated Command Prompt window and run the following command:

Sysprep /oobe /generalize

Other Considerations

There are a few other things that you are going to need to do to prepare a Windows virtual machine for the migration process. You will need to disable automatic logon (if the virtual machine happens to be using it), and you will need to make sure that there are no pending updates and no software is scheduled to be installed on the next reboot. You’ll also have to enable the RealTimeIsUniversal registry key.

My recommendation is to go ahead and apply all of the available updates before you attempt to export the virtual machine. There are a couple of hot fixes that Amazon requires, but these hot fixes are older and should not be required if you have installed all of the latest updates. In case you are curious, the required hot fixes are:

https://support.microsoft.com/en-us/kb/2922223

https://support.microsoft.com/en-us/kb/2800213

Perhaps the most important thing that you can do to prepare for the migration of a virtual machine is to plan for the migration process. This sounds really obvious, but there is a method to the madness. You can’t just live migrate a running virtual machine from one host to another as you can in a local Hyper-V deployment. The virtual machine is going to have to be taken off-line as a part of the migration process. This is where planning comes into play.

If a virtual machine is running a mission critical function, then taking the virtual machine off-line for an extended period of time probably is not going to be an option. That being the case, you may have to get creative when it comes to preparing for the migration process.

Your options for keeping the application online are going to vary widely depending on the application that you are running. In some cases however, it may be possible to keep an instance of the application running locally, and then replicate the application to a cloud-based virtual machine. That way, application components exist locally and in the cloud. You won’t be able to do this with every application, but some multitier applications do support this approach. In any case, you will have to come up with a plan for dealing with the extended downtime.

Conclusion

In this article, I have explained how to prepare a Windows virtual machine for migration to the Amazon cloud. In the next article in this series, I will show you how to perform the actual export process and I will show you how to import the virtual machine into the Amazon cloud.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top