Home > VMware > Easing the pain of a VMware audit

Easing the pain of a VMware audit

November 21st, 2012 Leave a comment Go to comments
Print Friendly

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;

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

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

Licensing compliance

As a result of the audit I’ve picked up a few facts about VMware licensing which are useful to know;

  • Licences are ‘geographic’ in that they must be assigned to a host in the country where the license was purchased. Presumably this is to stop you purchasing in a cheaper country but could be an issue for global companies with central purchasing.
  • VMware have a ‘consistent coverage’ policy which means every functional environment must use the same SNS support level. For example if you use VMware for production and dev/test then all production hosts should have the same support level, and all dev/test hosts should have the same level.

My audit script

Here’s the script I ran to collect data from a bunch of hosts and export it ready for an Excel spreadsheet;


#Connect to vCenter

Connect-VIServer <insert vCenter here> -WarningAction SilentlyContinue

&nbsp;

#Setup some variables for later use

$HostReport = @()

$servInst = Get-View ServiceInstance

$licMgr = Get-View $servInst.Content.licenseManager

$licAssignMgr = Get-View $licMgr.licenseAssignmentManager

#Query each host

Get-View -ViewType HostSystem | ForEach-Object{

$Report = "" | Select-Object -Property Hostname, version, MemorySize, cpu_num, core_num, vmotion_ip, Uptime, Lic

$Report.Hostname = $_.Name

$Report.version =$_.Config.Product.Version

$Report.MemorySize = $_.Hardware.MemorySize

$Report.core_num =$_.Hardware.CpuInfo.NumCpuCores

$Report.cpu_num =$_.Hardware.cpuinfo.Numcpupackages

$Report.vmotion_ip =$_.Config.Vmotion.IpConfig.IpAddress

$Report.Uptime =$([Math]::truncate(((Get-Date) - $_.Summary.Runtime.BootTime).TotalDays))

$Report.lic =$licAssignMgr.QueryAssignedLicenses($_.Config.Host.Value).getvalue(0).AssignedLicense.Name

$HostReport += $Report

}

$HostReport | Export-Csv "C:\HostReport.csv" –NoTypeInformation -UseCulture

Categories: VMware Tags: , , ,
  1. nnaga
    November 21st, 2012 at 18:34 | #1

    Great stuff..very thoughtful…much appreciated.
    Thanks
    Nag

  2. November 18th, 2013 at 10:13 | #2

    Very useful article.

    I see from the script you provided the audit with: hostname, version, memory, #cores, #cpu, vmotion enabled, uptime and license. Coupled with the location and status (prod, dev, etc) did you have to provide anything else?

    Did the auditor ask about affinity rules?

    • November 18th, 2013 at 10:53 | #3

      I don’t recall providing any other information, and certainly not affinity rules. I can’t think of any reason why VMware would care – affinity rules might be used for software licencing within the guest OS but shouldn’t impact your VMware costs in any way.

  1. No trackbacks yet.
*