A question I get a lot is “Brian, what can we be doing to prep our on-premises environment to be ready for VMware Cloud on AWS?” I decided I would walk through this with all of you today so that you too can prepare for a simple and seamless on-boarding experience with VMware Cloud on AWS.
We will cover the following topics:
One of the fastest and easiest ways to onboard content into VMware Cloud on AWS is using Content Library. If you are not using it already, this is a great way to get organized and prepare to share your corporate images, templates, OVAs, ISOs and scripts.
The way to achieve this is to create a local content library in your on-premises vCenter and begin to add your files to it. When you create your VMware Cloud on AWS SDDC you will then ‘Publish’ your content library and add a ‘Subscriber’ library within VMware Cloud on AWS. This will allow you to either synchronize all files immediately, or choose to synchronize on-demand (files will be downloaded in the VMware Cloud on AWS content library only when needed). To see an example of this in action, watch this video on uploading and deploying a virtual machine using Content Library.
VMware Cloud on AWS will allow customers to connect to both the Management Network and the Compute Network via IPSEC VPN. The management and compute networks are both segmented for greater security. If you wish to have on-premises workloads communicate with those on VMware Cloud on AWS, you’ll need to work with your Networking team to allow an IPSEC VPN connection from your on-premises network to your VMware Cloud on AWS networks. This is something you can work with your Network and Security teams on before getting your environment. When you DO get your VMware Cloud on AWS Environment, you will need to set the following:
For the most part, your PowerCLI scripts will work out of the box with VMware Cloud on AWS. However, because of a limited permissions model that is used since it is a managed service, there are a few tweaks you may need to perform on your library of scripts. Primarily, your VMs will be located in a parent Resource Pool (“Compute-ResourcePool”) and folder “Workloads”. Because of these permissions, trying to add a new VM to the datacenter level (default) of a vCenter will fail.
The list below are some of the cmdlets that may require you to update your scripts to include the resource pool and or folder
You can use the following line of code and run it against your repository of PowerCLI scripts to return any scripts (and the line it is found on) where you may need to add the additional parameters.
$array = @(“Import-VApp”, “New-Folder”,”New-ResourcePool”,”New-Template”,”New-VApp”,”New-VM”)
Get-ChildItem -Include *.ps1 -Recurse | Select-String -Pattern $array
Figure 1 – As you can see this returns every line in all my scripts that has use these cmdlets
Before you can deploy an SDDC in VMware Cloud on AWS, you’ll need to link your AWS account to VMware Cloud on AWS. This is for several reasons. The first is really around ensuring that you have accepted AWS’s Terms of Service (ToS) since VMware Cloud runs in AWS. Once your accounts have been linked you will be able to deploy your SDDC. The second reason is to allow you to integrate AWS services with VMware Cloud on AWS, and allow VMware Cloud on AWS to deploy a VMware Cloud Endpoint into a VPC for communication between the two. If you don’t already have an AWS Account, this would be a great time to get one set up.
Depending on your use cases for VMware Cloud on AWS, you may choose to migrate existing workloads up to VMware Cloud on AWS, or build VMs net-new. If you are choosing to move workloads from on-premises up to the cloud, you should start auditing your environment and begin looking at good candidates to move to the cloud. If you know your environment well, this can be a simple task. For those with many VMs and applications that talk to each other a lot, it can be a little more difficult or even a reason to try out vRealize Network Insight (vRNI) to see how all your VMs and applications are communicating with each other. The ideal way to start would be to take a look at workloads that are not super intertwined with others in your datacenter, meaning, you won’t have to worry about a lot of cross-communication between on-prem and cloud. This type of cross communication is not bad, but if you have latency-sensitive workloads that require this type of communication it could be possible that this impacts their performance, depending on a number of factors including your internet bandwidth and connectivity to AWS.
Now that we have discussed several items that can be accomplished now, go ahead and start prepping your environment. Looking forward to your comments on your progress and your success!