This was originally posted here. Visit VMGuru for more content from Dimitri de Swart and Erik Scholten.
Updated April, 2021
Whenever I talk to customers regarding vRealize Automation or Cloud Automation Services the same questions/remarks pop up on how to onboard existing workloads.
“This is probably only for green field deployments?!”
“Can I use this to manage existing workloads?
“What about my existing vSphere/AWS/Azure deployments?”
This is a hot topic and I understand that not all customers are able to start with a clean slate and to be honest, why should you. Only a small percentage of my customers have the luxury of starting with no history, no luggage and a decent cloud management solution should be able to do both. Start from scratch or onboard you existing environment.
I must admit, vRealize Automation is able to onboard existing workloads but it’s not the best, fool proof, low effort on boarding process I’ve seen. VMware’s new Cloud Automation Services however makes onboarding existing workloads simple again. So, how does that work?
Cloud Automation Services uses onboarding plans to add existing unmanaged machines to a Cloud Assembly project. Unmanaged machines are those machines that were created before their source cloud accounts were added to your Cloud Assembly project. You can onboard unmanaged machines by selecting them from a list or by using filters that match one or more machine conditions, such as name or IP address. These machines can be grouped in a single deployment or each machine can be onboarded as its own deployment.
First start with a simple onboarding plan. In Cloud Automation Services go to the Infrastructure tab and select Onboarding in the left column. Here we create a new onboarding plan which I named ‘vSphere 2 CAS’.
You select the cloud account you would like to onboard workloads from and you select a project to which the existing workloads will be assigned.
Next we select the workloads we would like to onboard. To do this, go to the Machines tab. Here you will see all the machines that are discovered using the specific cloud account. You can now simply select the machines you want to manage using Cloud Automation Services.
Once you’re done, select Ok and now you have four options to handle how the selected machines will be presented in Cloud Automation Services. You can create a new deployment or add the machine to an existing deployment and you have different options to group or seperate the machines.
You can now run the onboarding plan and because I selected to create a deployment for each machine, I ended up with seven new deployments in Cloud Automation Services.
This is a very easy onboarding process which is a hundred times better than with vRealize Automation. But besides that it’s very easy and basic it’s also static. You can use this process if you don’t have many machines to onboard and your environment is very static.
But what if you want to make this dynamic? You don’t want to spend a lot of time sorting through all machines and you especially don’t want to do this on a daily or weekly basis. Let’s see how to improve this onboarding plan.
To do this, select the existing onboarding plan and remove the machine selection. Then go to the Rules tab
You can create filtering rules to select machines for onboarding based on criteria such as machine name, status, IP address, and tags.
I’ve assigned two tags in my vSphere environment, ‘Managed by CAS‘ and ‘AppID‘. This creates the following scenario:
|Virtual machine||AppID||Managed by CAS|
The onboarding rule selects all the virtual machines which have the ‘Managed by CAS’ set to ‘Yes‘. This way you can easily include the virtual machine in the rule and therefor bring it under management by assigning this tag.
The second tagged called ‘AppID’ is used to group the applications into two separate deployments instead of five. The Finance application will contain two virtual machines (App_A_Web Server, App_A_DB Server). The HR application will contain three virtual machines (App_B_Application Server, App_B_Web Server, App_B_DB Server). To do this, go to the Onboarding rule Summary taband enter the Deployment tag key. This tag category (in vSphere speak) will be used to determine which virtual machine belong together and will be grouped into one deployment. When you’ve entered the Deployment tag key select Apply.
Now go to the Deployment tab and you will see the two deployments and the virtual machines belonging to each deployment.
Select both deployments, select ‘Blueprint’ and select the option ‘Create blueprint in Cloud Assembly format‘. This will create two new blueprints based on the existing workloads and the application construct you’ve just created using the tags.
Update (Dec 2020):
Adding Custom Properties to Onboarding Plan
Custom Properties can now be added to an onboarding plan within vRealize Automation Cloud (scheduled for release in vRealize Automation 8 in Q1 2021). You can now set customer properties at the plan or VM level during an onboarding setup. A custom property set at the virtual machine level will override the same property on a plan level.
The overall result is that you’ve created a dynamic onboarding rule which will detect new workloads tagged in vSphere with the ‘Managed by CAS’ set to ‘Yes‘. Which will be grouped according to the value entered in the ‘AppID’ tag category. The new onboard applications will then show up in Cloud Automation Services under the ‘Deployments tab’. Now you can start managing your workloads through Cloud Automation Services.
This dynamic nature of the onboarding rules is especially useful when IT Admins or Developers want to keep using the element managers like vCenter or the native Azure or AWS console. The auto discovery of new workloads will place them under management of Cloud Automation Services and will enforce the policies assigned to the specific project.
vRealize Automation 8.3 Updates
In vRA 8.3 we have added some additional improvement to onboarding plans:
- Onboard Disks attached to VM. Besides just the boot disk you can now onboard additional disks that are attached to the VM.
2. Custom Properties can be added to VM. The Custom Properties added to the VM can be seen when deployments are done.
3. Change owner when a deployment is created. In the onboarding plan you can now change who the owner will be once you do a deployment from the onboard plan. The users in the Project associated with the Onboarding Plan will be available.
Changing deployment projects for onboarded deployments
We now support the ability to change projects of a onboarded deployment as a Day-2 action. The ability to change project is currently only available for onboarded deployments. The same resource Cloud Zones should be present in the target project as well.
With the release of vRA 8.4, onboarded deployments can have Project membership changed. Once the deployment is onboarded, a Day-2 action is available which allows the Project to be changed.
The “Change Project” action is greyed out for deployments that weren’t onboarded. Also if you provision resources on the deployment after the deployment is onboarded, you will not be able to change Projects. Removing the post-onboarding provisioned resources will re-enable a Project change or that deployment. Confirm you have ownership and/or the necessary roles and permissions in the source and target Projects to make a change. Finally, make sure the target Project has the same Cloud Zone defined as the source Project.
You can “Unregister” onboarded VMs in vRA 8.4 as well. Unregistering a VM makes it available for a new onboarding workflow. Any attached disks, that were also onboarded, will be unregistered along with the VM.
One area to note, if you add disks after a machine has been onboarded, the machine will not be treated as onboarded any longer and the unregister functionality will not be available for that VM.
Request a Cloud Automation Services free trial and get a hands on experience of our new offerings.
Start a Cloud Automation Services Trial