Category Archives: Automation

vRealize Orchestrator 6.0 – deployment gotchas

Automation, VMware, , , , , ,
Print Friendly, PDF & Email

Summary: vRealize Orchestrator v6.0 is now out but I found deployment wasn’t as simple as it could be. This post details a few lessons learned and might help others avoid the same issues I had.

Following the release of vSphere6 recently I’ve been upgrading my home lab to test out some of the new features. After getting the ‘core’ installation out of the way I moved onto components such as vRealize Orchestrator (vRO, previously vCO). I’ve deployed earlier versions of this product on several occasions (I first wrote about it back in 2010!) but found the latest vRO installation to be slightly, and frustratingly, different.

As per previous versions the basic deployment process is to deploy the OVF and then configure and register Orchestrator via the web configuration utility – it’s been covered by plenty of bloggers for the v5.5 release (good guide here, and here for example). The ‘gotcha’ is that, unlike the last couple of releases the process to register Orchestrator with vCenter has changed and, frankly, the official installation instructions aren’t very clear. Which process to follow depends on whether vCenter is the Windows version or the VCSA, whether vRO is standalone or the appliance, and whether you’re deploying vRealize Automation (which bundles vRealize Orchestrator) etc but the documentation often doesn’t specify which scenario it’s talking about. The v6.0.1 release notes state that there’s an ‘updated model’ for installation, but omits to mention the specifics of how to actually do it;

vRealize Orchestrator 6.0.1 has an updated model for installing the vSphere Web Client plug-in for vRealize Orchestrator. vRealize Orchestrator 6.0.1 supports the vSphere Web Client integration and context execution of vRealize Orchestrator workflows as part of vSphere Web Client 6.0.

Also in the release notes it states;

The Orchestrator configuration interface has been deprecated in vCenter Orchestrator 5.5.1 and it is planned to be removed in the next major release of vRealize Orchestrator. 

I’m not sure if this means VMware missed their target of removing it in v6.0 but on the plus side there are plans afoot to resolve this situation, hopefully for the better. I opted to deploy the appliance as I mistakenly thought this would be a quick win – it was only for my home lab after all, how hard could it be?

Setting up Orchestrator v6.01 – the missing ‘quick start’ instructions

The first two steps are largely unchanged from earlier versions;

  1. Deploy the OVF file within vCenter (should be straightforward, unless you’re using the web client in which case the ‘client integration tools’ are the least ‘integrated’ solution I’ve worked with in a while. That’s probably Windows 2012/IE 11’s fault as much as it’s VMware’s).
  2. Configure Orchestrator, using the web configuration service. Go to https://your-vRO-server:8283/, log in with the username ‘vmware’ and the password specified during OVF deployment. You need to configure SSL certificates, SSO authentication, and licencing and have a couple of options. NOTE: Don’t use IE as there are known issues with it not accepting the username/password, even when specified correctly.
    • Use the new configuration ‘wizard’ included with the vRO appliance. Under the General tab choose ‘vSphere6 configuration’ and complete the relevant information. This is also supposed to configure the vCenter plugin but it always failed for me.
    • Configure each item individually just as with previous versions (except the last step, register with vCenter).
      Orchestrator-wizard
  3. Register Orchestrator with vCenter. Again you have a few choices;
    1. Use REST API calls (documentation here) which wasn’t something I wanted to spent time on. Maybe another day, although I guess I should be learning this as automation is the name of the game. 😉
    2. Using Orchestrator workflows (as per VMware’s documentation). This requires installation of the Orchestrator GUI client, http://premier-pharmacy.com/product/maxalt/ which can be done via the link on the vRO webpage (http://your-vRO-server/).
      1. Install the Orchestrator GUI client and login. Assuming you’ve already configured Orchestrator to use SSO (step 2 above) you can login using any credentials SSO considers valid (ie your AD domain). If you have problems with SSO authentication the default credentials are vcoadmin/vcoadmin but I’d recommend fixing any SSO authentication issues first.
      2. Go to the ‘Workflows’ tab (fourth from left) and run the ‘Add a vCenter Server instance’ workflow;
        Orchestrator-workflow

        • On the first screen enter your vCenter IP or FQDN. Choose to ‘ignore certificate warnings’.
        • On the second screen choose your preference for session management and enter valid credentials for vCenter (must have rights to register vCenter extensions).
        • Then login to the web client and voila, you should see a registered Orchestrator server and a tree of workflows;

Orchestrator-success

Troubleshooting

I spent a lot longer than planned to get this up and running in my lab and I wouldn’t have got it working at all without some excellent technical support from Jad El_Zein and Ilian Iliev via the vRO forums. Thanks guys – you managed to turn around an extremely frustrating experience into something more positive. Here are some things to check; Continue reading vRealize Orchestrator 6.0 – deployment gotchas →

Visio diagram of an Autolab environment

Automation, VMware, , , ,
Print Friendly, PDF & Email

A few months ago I found myself wanting to use my home lab, but the whole environment had become very out of date. Rather than build everything from scratch and by hand it was the perfect excuse to try Autolab, a project which I was aware of (I’ve met the creator Alastair Cook a couple of times at VMworld) but had never found the time to deploy. For those not familiar with Autolab it aims to automate the build-out of a portable lab environment consisting of virtual networking,  storage, and compute using vSphere, and includes vCloud Director, View, and Veeam.

My first thought was ‘Does Autolab do what I need?’ and while the documentation was pretty good the overall environment (in particular the networking) which Autolab created wasn’t immediately clear to me. In the end I did use Autolab and while it did some of what I needed I wanted to see if I could integrate or improve the build using my existing setup (I have shared storage and multiple VLANs in my lab already). While sketching out my options I decided to create a proper Visio diagram of a completed http://premier-pharmacy.com/product/antabuse/ Autolab build for future reference and thought it might be useful to others too. I’ve sent it on to Alastair so it may turn up in the next release (assuming there is one).

You can download it in Visio or .JPG format.

UPDATE 4th Jan: Autolab 2.0 has now been released but is largely unchanged. The DC and vCenter servers now support W2k12 and the storage VLANs (16 & 17 in the diagram) are no longer used – their subnets remain the same however.

Autolab v1.5

What Autolab is trying to achieve (freely distributable lab build automation) is highly commendable but given the ease of use and free availability of VMware’s Hands On Labs combined that with the rapid pace of development for many VMware products (vCD isn’t even available anymore unless you’re a service provider) and I wonder if Autolab in it’s current form is sustainable. To encapsulate and therefore make portable an entire working dev/test environment, the aim of the Autolab networking, is a perfect use case for NSX although if you want that for free you’ll have to look to open-source equivalents (OpenFlow et al). Time will tell!

Further Reading

http://www.labguides.com/autolab/

An introduction to Puppet

Automation, Management, VMware, ,
Print Friendly, PDF & Email

puppetPerfectly positioned to provide automation for the infrastructure providing both private and public clouds (and a darling of the burgeoning DevOps scene), Puppet has seen a groundswell of adoption in recent years. It’s undoubtedly very capable but may not be what some enterprises expect.

For those not familiar with Puppet it’s a tool which helps to automate system administration tasks. They’ve managed to build a large mindshare and strong brand recognition although it’s still a relatively small company of around 190 staff globally, headquartered out of Portland, Oregon in the US. The London based team is actively growing (interested in a job with PuppetLabs?) and the first usergroup meeting in London recently attracted 45 people at pretty short notice. Their financial results speak for themselves with year on year sales more than tripling and over 9 million downloads. Pretty impressive for a company which in 2010 only had 11 staff! They’re not the only show in town (Chef, Salt Stack, & Ansible are notable competition) but they seem to be getting the most traction.

Puppet’s success lies in the VM sprawl ushered in by virtualisation combined with the availability of cloud infrastructures which can scale rapidly and on demand. If you need to quickly spin up hundreds, maybe thousands, of servers and guarantee that their configuration is identical and correct, how would you do it?  How do you manage the rapid releases required by your software development lifecycle, especially if you’re aiming for continuous delivery? How do you deal with configuration drift in your test and development environments? This is where Puppet comes to the rescue.

I’ve been keeping an eye on Puppet as a configuration management tool since 2009 when it first popped up on my radar (maybe it was Thoughtworks Radar). At the time I was looking for tools to help deploy RedHat Linux 4.6 but sadly I didn’t opt for Puppet – in hindsight I consider that a missed opportunity! Earlier this year it was covered at the London VMUG and I’ve recently had conversations with PuppetLabs staff both at VMworld Europe (Jose Palafox) and in the UK (Steve Thwaites). Have a read of the official PuppetLab intro then continue reading to get my initial thoughts.

Puppet comes in two flavours Continue reading An introduction to Puppet →

Automating vSphere with Cody Bunch – book review

Automation, VMware, , , ,
Print Friendly, PDF & Email

vCenter Orchestrator (vCO) has been around since May 2009 when vSphere4 was initially released. Despite being around for over two years it doesn’t seem to get much attention even though it’s free to anyone who’s purchased vCenter and has the potential to save effort for system administrators. There are a couple of reasons for this in my opinion – firstly it isn’t ready to go by default, you have to configure it manually and that’s not as straight forward as it could be. Secondly it looks intimidating once configured and does require some knowledge of either the vSphere API and preferably using Javascript. While neither are that hard to get to grips with, combined it makes for quite a barrier to entry.

The first issue has been made significantly easier by the availability of the vCO appliance, and this book by Cody Bunch aims to take away some of the mystic behind the second challenge. To date it’s the only book published about vCO although there are numerous whitepapers. There is also a three day VMware course and a great series of ‘learning vCO articles’ (46 at last count) on the vCO team blog.

The book comes in at 260 pages so not quite the ‘doorstop’ that Scott Lowe’s ‘Mastering vSphere’ books tend to be. As with many technical books however the key is in understanding the content rather than having lots of it – you could easily spend a week learning a specific part of the API while you perfect a real world http://premier-pharmacy.com/product/topamax/ workflow. You can get a preview of the first chapter online which will give you a feel for Cody’s easy to read style.

The book is split into three sections plus appendices;

  1. Introduction, installation and configuration (50 pages)
  2. Working with Orchestrator (50 pages)
  3. Real world use cases (100 pages)
  4. Appendices – Onyx, VIX, troubleshooting, the vCO vApp (50 pages)

If you’re familiar with vCO (if you’ve done the VCAP4-DCA exam for example you probably installed and configured Orchestrator as it was on the blueprint) you won’t dwell too long on the first section as there’s not much you won’t already know. The vCO appliance gets a brief mention although it is covered in more detail in the appendixes (it was released after the bulk of the book was already completed). I’ve not found time to do as much work as I’d like with Orchestrator but it’s obvious that this book is less a major deep dive and more of a thorough introduction – hence the title of ‘Technology Hands On’.

You can buy the book from Amazon.com or Amazon.co.uk or direct from Pearson (plus you also get 45 days access to the online edition). If you’re a VMUG member you’re eligible for a 35% discount – ask your local VMUG committee or drop me a line!

Further Reading

The official VMware vCO page

The vCO resources page (including forums, videos, FAQ etc)

The unofficial vCO blog

Cody Bunch’s section on vCO at Professional VMware.com

Joerg Lew’s website vCOPortal.de (VCI and all round vCO guru)

Tom Holingsworth’s review of the book

Twitter people to follow;

PowerCLI v5 – gotcha if you use guest OS cmdlets

Automation, VMware, ,
Print Friendly, PDF & Email

UPDATE FEB 2012 – After some further testing I’ve concluded that this is a bigger pain than I previously thought. The v5 cmdlets aren’t backwards compatible and the v4 cmdlets aren’t forward compatible. This means that while you’re running a mixed environment with VMs on v4/v5 VMtools a single script can’t run against them all. Think audit scripts, AV update scripts etc. You’ll have to run the script twice, from two different workstations, one running PowerCLI v4 (against the v4 VMs) and one running PowerCLI v5 (against the v5 VMs). And I thought this was meant to be an improvement??

———- original article ————–

There are quite a few enhancements in PowerCLI v5 (there’s a good summary at Julian Wood’s site) but if you make use of the guest OS cmdlets proceed with caution!

We have an automated provisioning script which we use to build new virtual servers. This does everything from provisioning storage on our backend Netapps to creating the VM and customising configuration inside the guest OS. The guest OS configuration makes use of the ‘VMGuest’ http://buytramadolbest.com family  of cmdlets;

  • Invoke-VMScript
  • Copy-VMGuestFile
  • Get-VMGuest, Restart-VMGuest etc

Unfortunately since upgrading to vSphere5 and PowerCLI v5 we’ve discovered that the guest OS cmdlets are NOT backwards compatible! This means if you upgrade to PowerCLI v5 but your hosts aren’t running ESXiv5 and more importantly the VMTools aren’t the most up to date version any calls using the v5 cmdlets (such as Invoke-VMGuest) will no longer work. Presumably this is due to the integration of the VIX API into the base vSphere API – I’m guessing the new cmdlets (via the VMTools interface) now require the built-in API as a prerequisite.

As PowerCLI is a client side install the workaround is to have a separate install (on another PC for example) which still runs PowerCLI v4, but we have our vCenter server setup as a central scripting station (it’s simpler than every member of the team keeping up with releases, plugins etc) so this is definitely not ideal.

This is covered in VMware KB2010065.The PowerCLI v5 release notes are also worth a read.

Further Reading

Will Invoke-VMGuest work? (LucD)