In my previous article I described how to establish a VPN connection between an AWS VPC and an on-premises datacenter. The next logical step is moving workloads up to the VPC! In this article we’re going to use AWS native SMS service to do just that.
Pre-requisites for a VMware based environment here’s the tl;dr:
- vCenter 5.1 or higher (we’re be using 6.5 here)
- ESXi 5.1 or higher (again, 6.5 here)
- Enough disk and RAM to run the locally installed appliance that does the heavy lifting (20Gb & 8Gb respectively)
- The network will let you do it
- A supported OS for the victim migration target.
Install the SMS appliance
-
Log into the console and go to SMS:
-
I recommend 1st reviewing the “Getting Started Guide” link, then clicking Get Started:
-
You can either download the OVA, or use the deploy from URL option. We’re going to deploy from URL.
-
Log into vCenter, then right click on the cluster you want to deploy the OVA to and select Deploy OVF Template:
-
Input the provided URL:
-
Change the name & choose where you want it to go:
- Once the OVA is up and running, console into the box as ec2-user password ec2pass (and type in new password when prompted)
- Run the command sudo setup.rb
-
Select option 2 and check your ipconfig information:
- Make changes necessary so that the appliance can ping via FQDN, IP address, and short name.
-
Once that is completed, use a web browser to go to the IP address of the appliance via https and click “Get started now”:
-
Carefully read every line of the license agreement and click next:
-
Create another password for the management console:
-
If your NTP isn’t sorted, you will get the following error:
-
AWS recommends you leave the following checks checked… follow your corp policy on this one:
-
Use an IAM credential using the following instructions and put the Access/Secret Keys here:
-
Follow the instructions on creating a vCenter Service Account, then input the information & click next (since this is my lab I’m using admin creds… DO NOT DO THIS IN PROD!):
-
If you did everything correctly you’ll see this screen!
-
Now here we have the connector dashboard:
Let’s migrate a VM shall we? You can do this either via the console or CLI. For this exercise we’ll use the console. Log back into the AWS console and go back to Server Migration Service. Now we see something different!
-
In the navigation menu, choose Connectors. Verify that the connector you deployed in your VMware environment is shown with a status of healthy:
-
Choose Servers, Import server catalog:
-
Select a server to replicate and choose Create replication job:
-
On the Configure server-specific settings page select the license type for instances to be created from the replication job:
-
On the Configure replication job settings page, the following settings are available:
-
For Replication job type, choose a value. The replicate server every interval option creates a repeating replication process that creates new AMIs at the interval you provide from the menu. The One-time migration option triggers a single replication of your server without scheduling repeating replications.
-
For Start replication run, configure your replication run to start either immediately or at a later date and time up to 30 days in the future. The date and time settings refer to your browser’s local time.
-
For IAM service role, provide (if necessary) the IAM service role that you previously created (note that you will HAVE to do option 2, option 1 in the AWS documentation does not work).
-
For Enable automatic AMI deletion, configure AWS SMS to delete older replication AMIs in excess of a number that you provide in the field (note that this isn’t a great way to do backups… but it’s a way… )
-
For Enable notifications, choose a value. If you choose Yes, you can configure Amazon Simple Notification Service (Amazon SNS) to notify a list of recipients when the replication job has completed, failed, or been deleted.
Choose Next:
-
-
On the Review page, review your settings. If the settings are correct, choose Create:
-
One item the AWS documentation got wrong. When you create the sms role, you must manually go back in and edit the trust relationship and input the following values:
{
<
p style=”margin-left: 18pt”>
“Version”: “2012-10-17”,
<
p style=”margin-left: 18pt”>
“Statement”: [
<
p style=”margin-left: 18pt”> {
<
p style=”margin-left: 18pt”>
“Sid”: “”,
<
p style=”margin-left: 18pt”>
“Effect”: “Allow”,
<
p style=”margin-left: 18pt”>
“Principal”: {
<
p style=”margin-left: 18pt”>
“Service”: “sms.amazonaws.com”
<
p style=”margin-left: 18pt”> },
<
p style=”margin-left: 18pt”>
“Action”: “sts:AssumeRole”,
<
p style=”margin-left: 18pt”>
“Condition”: {
<
p style=”margin-left: 18pt”>
“StringEquals”: {
<
p style=”margin-left: 18pt”>
“sts:ExternalId”: “sms”
<
p style=”margin-left: 18pt”> }
<
p style=”margin-left: 18pt”> }
<
p style=”margin-left: 18pt”> }
<
p style=”margin-left: 18pt”> ]
}
-
If you don’t do this, the job will fail. If you get the trust right, you will see the following screen:
-
Let’s check in on the job:
Things are looking good! I’ll update the article if I run into any more gotchas!
thanks Chris,
great help, i am getting an error when i am trying to create replication job, and error is ” Unable to create replication jobs for ….” >> the service role doesn’t exist or hasn’t been granted permission for the service to use ” me being very new to AWS can you please suggest any solution?
Shaikh,
Check your IAM roles & permissions for the account that you are using to create the job.
Hi Chrisf,
Good blog, hope I could step into it earlier. I’ve been trying to implement this multiple times with an AWS China region account and it keeps fail with “Job status message: Unable to create import tasks for sms-job-XXX,sms-run-XXX”. My connector was healthy and each time there is a snapshot created message in the vShpere Client while unable to upload to AWS S3. Do you by any chance know about this? Be hearing from you.