I recently had to complete an external audit of our VMware estate and thought it might be useful to others to know what the process entails, what you’ll need to provide to the auditors, and a few issues that I wasn’t aware of beforehand around licencing compliance. The initial approach by the auditor will describe the overall process and expected timelines (which will vary based on the size of your company).
There are two main steps in the process – self disclosure and discovery;
- Self disclosure is where you detail your use of VMware software including vCenters, ESX/ESXi hosts, VMs, and licences. In our case this was collated into an Excel spreadsheet provided by the auditor (the deployment detail workbook). You’ll also have to answer some high level questions about your company (such as how many locations you have), how you audit internally (how you track licences – third party tools, vCenter etc), when you initially deployed VMware in your company, and some info about your contacts for the audit. How you collect this information is up to you but there are a couple of good choices;
- Export data from vCenter using the GUI
- Export date from vCenter using PowerCLI scripts
- Use third party tools.
I used a mixture of RVTools (which is a handy and free download) and PowerCLI scripts. The native ‘Export’ feature in vCenter isn’t very flexible (there’s no way to export all the MAC addresses of VMs for example) but while RVTools came close it didn’t provide everything I needed either. I needed host uptime and while RVTools does show the last reboot time I still needed to translate that into days plus it didn’t cover licencing for each host (which I could have got from vCenter). I’ve included the script I ran at the end of this post in case it’s of use to someone else.
- Validation. Once the disclose is completed the auditor will want to ‘validate’ the information – auditor talk for “are you telling the truth, the whole truth, and nothing but the truth?”! This can be done in a variety of ways depending on the size of your estate, location, the auditor etc. It could include using your inhouse auditing tools (Centennial for example), data from directories like Active Directory or a scan of your network switches for a list of VMware MAC addresses (prefixes 00.05.69, 00.0C.29, 00.1C.14, as well as the more commonly known 00.50.56) . The latter was the approach we took due to a mixed Linux/Windows estate and the auditors preference. NOTE: you’ll do the actuall collection of all data not the auditors, even if they’re onsite.
In an ideal world the information collected in this step matches up nicely with the information you’ve disclosed – any discrepancies will need investigating and explaining. A few things that caught me out here;
- Ensure you keep track of any changes to the VMware environment after the audit process kicks off (this is an audit requirement). Some of my discrepancies were because another admin had decommissioned some VMs after my initial disclosure so they flagged up as ‘missing’. Simple to explain, but time consuming to track down! This could be a real challenge in a larger environment.
- Remember that VMkernel ports also have VMware MAC addresses, not just the VMs. I spent a while trying to find ‘phantom’ VMs before tracking down the issue. RVTools shows these in a seperate tab so you’ll need to export both.
- Even if you’re over entitled (you have more licences than you’re using) you’ll probably have to justify it, just to be sure you’re not hiding some part of your installation.
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;
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;
- 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.
Will Invoke-VMGuest work? (LucD)
Written by some of the top scripters in the VMware community the PowerCLI Reference book is really what it’s title states- a reference. What it does (and does very well) is present both a ‘cookbook’ of useful scripts and explain how and why they work. While it does explain some concepts along the way it’s not really pitched as an introductory guide or as the best way to learn PowerCLI (Hal Rottenberg’s book might be better if this is what you’re after). The book is split into five main sections (see the full table of contents);
- Install, configure and manage the vSphere environment. This section deals with vCenter automation, host deployment along with automated storage and networking provisioning.
- Managing the VM lifecycle. Deals with creating, customising, and configuring VMs and vApps.
- Securing vSphere. Covers backups, DR, security hardening and compliance.
- Monitoring and reporting. Generating reports, statistical data, monitoring and auditing.
- Scripting tools and features. Covers automation in general, the APIs (Get-View etc), Onyx, and common tools such as PowerGUI and PowerWF Studio. This chapter also covers adding a GUI to your scripts which is very useful for scripts that others need to use.
As you can see from the above list (and the fact it’s over 700 pages) it covers a lot of material but despite this I’m impressed with the technical depth on each – I picked areas where my knowledge is strongest (though not in the same league as these guys) and still found myself learning something new everytime. For example I’ve used the VIX API while creating a scripted deployment for my test and dev environments at work and thought I knew it reasonably well. To my surprise the book delved into the inner workings of the cmdlets themselves and explained how they in turn called some guest OS scripts which ship with PowerCLI. There was also had a good script for specifying a VM folder location via script, something I’d not implemented before as I couldn’t think of an easy way to specify the path. The index lists the pages where each cmdlet is used so it’s easy to look up the cmdlet you’re interested in and see code examples.
The scripts are downloadable from the book’s very own website and the authors have even put together a module containing all the code along with instructions for how to use it. This is a major bonus – you get nearly 80 prewritten functions you can integrate into your own scripts! These are useful for day to day administration, not just esoteric or niche functions. It’s worth checking this site out even if you’ve got the book – there are forums to discuss the scripts and at the moment they’re running a competition where to be in with a chance of winning you just have to take a photo of the book with a well known landmark in the background (ala ‘the orange HA book’ by Frank Denneman and Duncan Epping). I’m not sure how popular this will be as it’s a beast of a book to carry around, but that just means you’re chances of winning are that bit better!
It’s available in colour paperback or Kindle version (which is newly available again).
Disclosure – I’ve met both Jonathan Medd and Al Renouf at the VMware User Group on several occasions and was sent a copy of the book to review. There was no obligation to write a positive review and I’ve said it as I see it. I’d have bought the book anyway!
PowerCLI has been increasingly popular due to the need to automate larger vSphere environments. This section, more than most on the VCAP-DCA blueprint is one where you have to know what you’re doing – writing code can’t be done in theory, you have to get stuck in and play with it.
The main references for this section are the VMware PowerCLI homepage and the VMware PowerCLI Administration guide. PowerCLI has received extensive blog coverage from numerous people far more experienced than me – check out Virtu-Al, Luc Dekkens, Hal Rottenberg or Jonathan Medd’s blogs for more info than you can handle….
PowerCLI is simply an extension to Microsoft’s Powershell environment so installation consists of installing Powershell (it’s built into Windows 2008 onwards) and then adding PowerCLI;
- WinXP SP2, Win2k3 or greater
- 32 or 64 bit
- .NET framework v2.0 SP1 (or greater)
- Powershell v1 or v2
- ESX or ESXi v3.0, vCentre 2.01 (or greater)