Tag Archives: PowerCLI

Prerequisites check vCAC 6.1 (automated)

As many of you already know VMware released vCloud Automation Center 6.1 September 9th. I’m working on an implementation already, so I feel pretty lucky. An installation always starts with the deployment of the necessary Windows (2012R2) servers and all the prerequisites listed in the documentation.

We at automate-it.today are big supporters in automating everything, as long as it useful or fun to build. So I was really excited about the pre-req automation script build by Brain Graf. It’s easy, it’s fast and will give you a good verification of all the necessary prerequisites.

You can find the script here.

 

Automating SRM with PowerCLI

Update (11-sept-2014): VMware released a vCO plugin for SRM. So if you are looking to automate SRM with vCO don’t use the Powercli script below but use the plugin instead.

Recently I was working on automating the deployment of VMs on a twin datacenter vSphere design. The failover is handled by Site Recovery Manager and the deployment of the VMs is taken care of by vCAC. Luckily vCAC has SRM integration so no prolem there….. But apparently when VMware says “integration” they mean: “It’s ok if you failover VMs deployed by vCAC”. It doesn’t mean that all VMs deployed by vCAC are automatically protected by SRM. Since we are using vCAC the logic choice would be to automated this using a vCenter Orchestrator workflow that enables protection for the deployed VMs. However, there is no vCO plug-in for SRM and SRM does not have a REST or SOAP API. At least not one that is compatible with the vCO SOAP plugin. This, to me, is surprising because both SRM and vCO have been around for quite a while. Luckily the latest version of VMware PowerCLI comes with SRM cmdlets. Or rather: one cmdlet. Now, vCO can call Powershell scripts so the obvious solution is to create a powershell script that configures SRM protection for a virtual machine and then call that from vCO.

The first thing I tried was copy pasting the example from the documentation. Which didn’t work. It kept failing with the error:

The operation is not supported on the object”

The same error was reported here but no solution available. The error was caused by the line containing: “associateVms()“. It turns out I should have just read the developers guide because that states this method is only needed when you’re using SRM Replication. If you are using array based replication there is no need to associate the VM with a protection group. However, removing this line only resulted in a new error. This time the error appears in the vSphere client:

Not authenticated into SRM server <servername>

The account I was using has administrator permissions on both vCenter servers and both SRM machines so it’s not a permission issue. The solution is to pass credentials with Connect-srmserver command for both the local and the remote SRM server. Below is the script I created. It takes the vCenter server ,a username, the VM to protect and the protection group it is in as parameters.

Please notice the “$password =” line in the script above. This reads the encrypted password for the user account from a password file in c:\orchestrator\powershell. Passing the password as plain text was not an option. Typing it obviously is impossible if you want to run the script from a vCO workflow. To solve this I store the password encrypted in a file. The password file is created using the script below:

This script takes a username as an input. You want to use the UPN here (user@domain). The script doesn’t generate any output on the screen. Just start the script, type the password for the user and you’re done.

Now we want to kick this off from vCO. That’s where it gets a little tricky because the script will probably not run under the account you use to develop and test the script. The thing is, the password file that is generated by the script  above is encrypted with a key specific to the use running the script. In other words: we need to run the script under the same account that will be used to run the srm protect script (in my case the vCO service account). Here is how to do it from a windows cmd prompt:

Now you’re ready to protect VMs automatically. I’ll explain how to run it from a vCO workflow in another post.

For now I’ll leave you with an additional script which you’ll need to unprotect the VM. Could come in handy when you want to automate the deletion of VMs.

How to Automate: PowerCLI

After writing my blog posts about the why and the what of automation I decided to write a bit about how to automate. This series of posts won’t go into much technical detail but rather offer some pointers to help you choose the right tool for the job.

When you think of automating tasks in a vSphere environment the first tool you probably think about it PowerCLI. For all less technical readers out there: VMware vSphere PowerCLI is a command line interface tool for automating vSphere tasks.

The Upsides

PowerCLI has the backing of a huge community. There are also plenty of books on the subject. On top of that there are a lot of command lets available from all kind of vendors so it integrates easily with a lot of products.

Thanks to the huge community it is pretty easy to learn PowerCLI or to build your scripts by just recycling code that can be found online and in books.

Another upside is that it is object oriented. This makes passing around information and monipulating the information pretty easy

The Downsides

The object oriented nature of PowerCLI could also be a downside depending on where you’re coming from. If you are used to writing bash scripts then some of the PowerCLI syntax may seem familiar but handling objects can be confusing.

Another disadvantage in my opinion is that you need a windows machine to run powershell. Me being a linux guy I really don’t feel a need to run any windows machine. Especially in lab environments where you can get away with running vCenter VA instead of the windows installation.

The last disadvantage is not specific for powerCLI but applies to scripts in general: Simple tasks are easy to automate but more complex tasks or long processes will result in huge scripts or piles of scripts which are hard to understand and very hard to troubleshoot and modify if needed.

The right tool for the job?

So is powerCLI the right tool for your job? Of course this depends on what the job is. I think it’s the right tool if you’re automating vSphere administration tasks. In that case it can make your life easier and save time. But if you try to automate whole IT Operations processes I highly doubt if this is the right tool you. More on that in a future blog post.