www.vExperienced.co.uk

After moving my blog to a new hosting provider last month I was reviewing the WordPress plugins I use and I found myself wondering if Alex Gorbatchev’s SyntaxHighlighter supported PowerCLI. The WordPress plugin I use (courtesy of Alex Bond) had a Powershell plugin but no PowerCLI. Time to create! I’m by no means the first person to extend this plugin and I quickly realised there were two options;

• upload a new ‘brush’ file to overwrite the existing Powershell brush. That change would be lost however if you upgraded the WordPress plugin and with the imminent release of Powershell v3 it could also be lost if the original Powershell brush was updated.
• write an extra plugin which includes the new language. I felt this was a bit more work, but generally the better solution (plus I was half doing this to learn more about WordPress and the plugin structure). With clear guidance on how to create new languages the hard work was already done.

The result is my WordPress plugin for PowerCLI syntax highlighting which includes;

• PowerCLI cmdlets up to v5.01 (including AutoDeploy, ImageBuilder, vCD etc)
• VMware Update Manager cmdlets
• The vSphere PowerCLI Reference book cmdlets.

Read more…

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

The blueprint for this section seems to refer mainly to ESX but I’ve described both ESX and ESXi on the assumption the lab environment used for the exams will move to v4.1 sooner rather than later.

NOTE: Weasel is VMware’s scripted installer. It’s similar to Kickstart as used with Linux, but not identical.

A summary for a scripted install;

• Decide on the bootloader source
• Configure a media repository to hold your source files and scripts
• Create an install script (either from scratch or from a previously built host)
• Perform the scripted install

Use cases for scripted installations

Reasons to use a scripted install;

• Reduce deployment time
• Ensure consistency, reduce human error
• Remove need for local media (when using PXE boot. Very useful for blade and remote environments)
• Delegate installations to junior staff who don’t know how to configure ESX

Along with knowing why you might use a scripted install in the first place you should consider the various types of scripted install and when to use each one. Factors to consider;

• Maintainability. Over time you’ll want to update your install for new releases of ESX, patches, post install steps etc. While a custom CD has the least dependencies it’s harder to maintain compared to a network media repository.
• Dependencies. I created an NFS based install only to find that most of the time the host’s physical networking hasn’t been completed when we want to build the OS, rendering this method useless. I had to convert it to a custom CD instead which was mounted via ILO (it was a blade environment). Another example is USB flash – it’s easier than CD to amend/update but may not be as useful for remote installs.

Read more…