In this episode, Sunny gave us a deep dive into the WLP and WLB features of vROps. We were also joined by a special guest, Jad El-Zein who gave us a great insight into how vRA utilises vROps for initial placement of freshly provisioned VMs We would highly appreciate it if you could spend 30 seconds to fill up this quick and simple survey to provide us your feedback. You can also request topics of your choice through this survey.
This was as I expected, the busiest day sessions wise for me. There was so much good stuff I had to be a little ruthless on what I wanted and or needed to attend while also wanting to get into the solutions exchange. Also at the end of the day the customer appreciate party was scheduled so that was something I was looking forward to a great deal (Hint - Kaiser Chiefs)
As a consultant I’ve had the opportunity to design, install and configure dozens of production vRealize Automation deployments, from reasonably small Proof of Concept environments to globally-scaled multi-datacenter fully distributed behemoths. It’s fair to say, that I’ve made mistakes along the way - and learned a lot of lessons as to what makes a deployment a success. In the end, pretty much everything comes down to getting the pre-requisites right. Nothing that I’ve written here is not already documented in the official documentation, and the installation wizard does a huge amount of the work for you.
I already have a vRealize Orchestrator workflow to shutdown my workload cluster. What I want to do is trigger that by a voice command from Alexa. Now, the correct and proper thing to do here would be to create a new Alexa skill, write the function in Lambda and connect that to my Orchestrator REST API and execute the workflow. That way I could control the “intents” and “utterances” and have verbal feedback.
In this humble consultant’s opinion, Log Insight is one of the most useful tools in the administrator’s tool belt for troubleshooting vRealize Automation. I have lost count of the number of times I’ve been asked to help troubleshoot an issue that, when asked, people don’t know which log they should be looking at. The simple fact is that vRealize Automation has a lot of log files. Correlating these log sources to provide an overall picture is a painful, manual process - unless you have Log Insight!
One of the cool new features released with vRealize Automation 7.2 was the integration of VMware Admiral (container management) into the product, and recently VMware made version 1 of vSphere Integrated Containers generally available (GA), so I thought it was time I started playing around with the two. In this article I’m going to cover deploying VIC to my vSphere environment and then adding that host to the vRA 7.2 container management.
Recently I’ve been working on some ideas in my lab to leverage the AWS endpoint on vRealize Automation. One of the things I needed to get working was getting Software Components working on my AWS deployed instances. The diagram to the right shows my end-stage network - the instance deployed by vRA into AWS should be in a private subnet in my VPC, and should use my local lab DNS server and be able to access my vRA instance.
When you’re working with Amazon and vRealize Automation Software Components, one of the requirements is for the Guest Agent (gugent) to talk back to the vRealize Automation APIs - the gugent polls the API for tasks it should perform, downloads them from the API and executes them, then updates the tasks with a status. This means that Virtual Machines deployed as EC2 instances in an AWS VPC require the ability to talk back to internal corporate networks - not something you’d want to publish on the internet!
Although it’s fairly limited, you can add AWS as an endpoint for vRealize Automation 7 and consume EC2 AMIs as part of a blueprint. You can even add the deployed instances to an existing Elastic Load Balancer at deploy time. In this post I’ll run through the basics to get up and running and deploy your first highly available (multiple Availability Zone, load balanced) blueprint. Preparing AWS for use as a vRA endpoint There are some obvious pre-requisites for attaching an AWS endpoint - for example, you need to have a VPC configured.
Big thanks to Jose Luis Gomez for this solution, his response to my tweet was spot on and invaluable! I’ve been trying to configure vCloud Air as a vCloud Director host in vRealize Orchestrator in order to create some custom resource actions for Day 2 operations in vRealize Automation. What I found was that there’s *very* little information out there on how to do this, and I ended up writing my own custom resource mapping for the virtual machines to VCAC:VirtualMachine objects - at least that way I could add my resource action.