Importing a Virtual Machine into Amazon EC2 (Part 2)

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

In the first part of this article series, I began laying out some of the requirements involved in migrating a virtual machine from an on premise hypervisor to Amazon EC2. In this article, I want to continue the discussion by talking about the general procedure that you will be using for the virtual machine migration.

Virtual machine migration to AWS EC2 is based on export / import. If you have ever worked with some of the earlier versions of Microsoft Hyper-V then you may be familiar with the concept of exporting a virtual machine and then importing it into another Hyper-V host. Migrating a virtual machine to AWS works similarly except that you must export the VM from your on premise hypervisor and then import the virtual machine into AWS.

Unfortunately, this process isn’t nearly as seamless as the old Hyper-V export / import because you are moving the virtual machine between two completely different platforms. Furthermore, the procedures that you are going to need to follow vary widely depending on the local hypervisor that you are using and on the guest operating system that is running on the virtual machine that you want to migrate.

As I discussed in the previous article, the export / import process is versatile. Windows, Linux, and Mac OS X are all supported as guest operating systems (although there are some version specific limitations). Common hypervisors such as VMware, hyper-V, and Citrix are also supported.

My plan is to focus the bulk of the discussion within this article series around migrating a Hyper-V virtual machine that is running Windows as the guest operating system. It is worth noting however, that Amazon currently offers a better migration experience from VMware than from other hypervisors. That being the case, I plan to show you the VMware migration experience later on in this series.

Installing the Required Tools

As I mentioned in the first article in this series, there are some tools that you are going to need to use in order to work through the migration process. Since I am going to be working in a Windows environment, I am going to need to use something called the Amazon EC2 Command Line Interface (or simply CLI for short).

The Amazon CLI tools are java based and are encapsulated in a ZIP file. One of the really nice things about the tools is that they do not have to be installed. You can simply download the file, unzip it, and use the tools. You do however, have to install Java in order for the tools to work. You can download Java from https://java.com/en/download/. You can download the Amazon CLI Tools at: https://aws.amazon.com/developertools/351.

Once you have downloaded the CLI tools, you will need to set the JAVA_HOME environment variable. The CLI tools look to this environment variable in order to locate the Java runtime.

To set the JAVA_HOME runtime variable, right click on the computer’s “start button” and then choose the System command from the shortcut menu. When Windows displays the System dialog box, click on the Advanced System Settings link. This will cause Windows to open the System Properties dialog box.

At this point, you will need to select the dialog box’s Advanced tab and click the Environment Variables button, as shown in Figure A.

Figure A: Click on the Environment Variables button.

Windows will now display the Environment Variables dialog box. As you can see in Figure B, this dialog box is divided into a User Variables section and a System Variables section. You will need to click the New button that is attached to the User Variables section.

Figure B: Click the New button that corresponds to the User Variables section.

You will now be prompted to enter a name for the environment variable that you are creating. The name should be JAVA_HOME. You must enter this name in all caps.

Next, you will have to enter a value for the variable. The value must be set to reflect the path to the Java home folder. You must make sure that you do not include the BIN folder in the path. Otherwise the CLI Tools won’t work. The actual path that you will use will vary depending on how you have installed Java. Assuming that Java has been installed to the default location, the path will be C:\Program Files (x86)\Java\jre <version number>. You can see what this looks like in Figure C. Click OK three times to complete the process.

Figure C: You must enter the path to your Java home folder.

Now that the environment variable has been set, it is a good idea to test the variable to make sure that it is working properly. This is surprisingly easy to do and the technique will probably be familiar to those of you who grew up with DOS like I did.

To give you a quick crash course in ancient history, the old DOS operating system has its own scripting language that was often referred to as batch programming. While batch programming was far more modest in its capabilities than PowerShell is, it had a variety of uses. One common batch programming technique involved using environment variables as a way of defining constants. Those variables could be referenced within the batch file by placing a percent sign before and after the variable name. We can use the same technique to reference the environment variable that we have just created because the Windows Command Prompt is largely backward compatible with DOS versions from over 30 years ago.

OK, so enough with the history lesson. Let’s take a look at how the environment variable works. To do so, open a command prompt window and enter the following command:

Echo %JAVA_HOME%

Upon entering this command, Windows should display the Java home path, as shown in Figure D. If you receive an error message then you may need to reboot your system in order for the environment variable to take effect.

Figure D: Entering Echo %JAVA_HOME% should cause Windows to display the Java Home path.

Once you confirm that the %JAVA_HOME% environment variable truly does contain the path to the Java home, you need to check to make sure that Java is working and that it is accessible from the command prompt. The easiest way to do this is to perform a Java version check. To do so, enter the following command:

“%JAVA_HOME%”\bin\java –version

If everything is set up correctly then Windows should display Java’s version information. You can see what this looks like in Figure E.

Figure E: If the Java version information is displayed then the environment variable is configured correctly.

As you may know, all of the Java executables exist within Java’s BIN folder. That being the case, Amazon recommends adding the Bin folder to the system path. To do so, open the System dialog box as you did earlier, select the Advanced tab, and click the Environment Variables button. Now, locate the Path variable contained in the System Variables section. Select the Path variable and click the Edit button.

The Path variable contains a number of different paths. Move your cursor to the beginning of the list of paths and enter %JAVA_HOME%\bin; Make sure that you do not accidentally overwrite any of the existing path values in the process. Click OK a few times and then reboot the server.

When the server reboots, enter the following command:

Echo %path%

Check for the existence of the code that you just added to the path.

Now, simply enter:

Java –Version

You should now see the java version displayed, as shown in Figure F. This proves that Java is accessible from the default path and we can move forward with the Amazon CLI tools.

Figure F: Java should now be accessible from the default path.

Conclusion

In this article, I have shown you how to prepare the system for the use of Amazon’s CLI tools. In the next article in this series, I will talk some more about these tools.

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