Category Archives: Management

I recently attended the tech.unplugged event in London (my thoughts on it are here) and the London VMUG the following day, and was in the right place at the right time to take part in the InTechWeTrust podcast, episode 32. For those not familiar with this podcast it’s run by a prominent team of bloggers who have a background in enterprise infrastructure and has been going since last September. You can listen to the podcast directly via the player below or your usual choice of subscription (iTunes etc) – just head on over to the InTechWeTrust website for all the links.

Make sure you listen to the last 15 mins with EMEA CTO Joe Baguley – very interesting.

I’d like to use this blogpost to follow up on some of the topics discussed and my contributions.

...on ‘containers’. Sometimes I find myself speaking on a topic of which I’m by no means an expert – I try to avoid it as I’m all about facts, impartiality (as far as that’s possible) and I’m a believer that your reputation is sacrosanct (not just in the bloggersphere) but you can’t learn without getting out of your comfort zone. I’m not a developer. I have limited knowledge and minimal hands-on experience of containers. I have an understanding on where they fit into an overall architecture, who’s getting value from them, and at least an inkling of their potential but I’m clearly no expert. My comments about Docker building a platform (with an implied degree of vendor lock-in) vs Rocket’s ‘more open’ ambitions largely came from reading this blogpost from Rocket, this great Reddit thread discussing what it means, plus a good http://premier-pharmacy.com/product/strattera/ summary from GigaOm. Clearly this still needs to play out – the stakes are high and it’s going to be an interesting ride!If anyone can point me to other resources with more information I’d be very grateful!

…on Photon/Lightwave/Photon. This was discussed with Joe Baguley after I’d left the podcast but the interesting soundbites for me were ‘a new direction for VMware’, the fact that containers are seen to be the boundary between VMware and Pivotal (hence why Photon/Lightwave are VMware yet Lattice is Pivotal), and the idea that containers may become embedded in vSphere itself. Interesting times!

…on Netapp. There’s been a recurring discussion about Netapp on the last few episodes and a good Linked-In discussion. I was a Netapp user for over five years (and I’ve written quite a few Netapp blogposts) and while I’ve not kept an eye on their latest releases I’ve always felt they weren’t vocal enough in the social media space, especially since Vaughn Stewart jumped ship to Pure Storage. This has improved with Nick Howell’s useful DatacentreDude blog and podcast but I still don’t see enough innovation. Flash, tiering, and scale out have all been addressed but never in a convincing way – the gravity of the core ONTAP OS seems all consuming. This would seem to be borne out in their upcoming layoffs. Again, happy to be educated otherwise!

Share this:

Summary: The vSphere Webclient has been around since vSphere 5.0 but it’s fighting an uphill battle to gain user acceptance. I’ve recently tried using it as my primary administration tool with mixed success.

Recently I’ve been rebuilding my home lab to test out new features in vSphere6 among others. As VMware have been very vocal about moving to the webclient I thought it was about time I took the plunge and started using it in anger – after all it’s been out for several years and like many others until now I’ve stuck with the C# client. Unfortunately I can’t say it’s been an overly positive experience, largely because of browser compatibility issues rather the the design of the webclient itself. To be fair it does seem faster than in earlier releases. VMware KB2005083 lists the prerequisites for the WebClient (both server and client components) but it doesn’t detail the browser specific configuration you need to get it working successfully. This post will cover a bunch of settings you need to make but it’s largely for my own reference as I couldn’t find a single source of information elsewhere.

Browser and server tweaks to make it work

Surely one of the perks of a web based client is no client side setup right? Sadly no. I’m using a Windows 2012 server as my management station for my home lab, which isn’t representative of a real production environment as I’m less concerned with compliance, security etc. While mine is a niche use case some of the same settings apply to desktop Windows editions, especially Windows 8. There are a few configuration changes you need to make on Windows to allow you to work with vSphere via the web client;

Enable desktop experience (instructions in VMware KB2054049) to allow Flash which is required by the web client (this is only required on Windows Server editions).

Install the client integration plugin as Administrator, run IE as Administrator. Discussed in this http://premier-pharmacy.com/product-category/other/ forum post (and this one) though I’ve had mixed success getting it to work at all. Based on the fact that those two forums posts between them have over 50,000 views I’d say this is a very common issue and one that seems to vary with each browser.

Disable Protected mode (internet and intranet zone) as per VMware’s advice. Obviously this reduces the security but if you’re choosing to use client applications on a server you’ve already made that choice!

Install the root CA certificate (instructions here) to remove those annoying ‘this site is untrusted’ errors. Alternatively deploy certificates to replace the self-signed one’s that ship with vSphere, although that’s considerably more work!

Disable pop-up blockers for the following sites;

I’m not sure if VMware publish a compatibility matrix across all their products but I’d suggest you have two different browsers installed so you can switch between them as required. For example IE is supposedly the fastest when using the webclient (reference), but doesn’t work at all when trying to login to the Orchestrator configuration web service.

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;

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?

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).

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.

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.

Go to the ‘Workflows’ tab (fourth from left) and run the ‘Add a vCenter Server instance’ 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;

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→

Share this:

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).

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.

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!

Share this:

Perfectly 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.

Disclaimer

These rants and raves are solely my opinion and do not reflect the opinions of my employers.
Any of my code, configuration references, or suggestions should be researched and verified in a lab environment before attempting in a production environment.
Agreement to use any of my code or recommendations removes me from any liability as such....and I shamelessly stole this disclaimer from Jase McCarty's site!