Enterprise Admins.org

I’ve been doing a lot of P2V migrations over the last few months and wanted to share a couple of lessons learned. Our environment uses McAfee ePO to centrally manage our desktops and servers. We noticed that after a P2V migration the agent would no longer be able to communicate with the ePO server. After doing some searching we located several registry keys that contain Agent keys unique to a specific piece of hardware. If we delete these keys and restart the framework service clients are again able to communicate. Additionally, I look through the device manager and remove old devices — such as network cards that are no longer installed. Since these steps are repetitive, and I have a large quantity of P2V’s, I created this simple batch file to help me out:

[cc lang=”dos”]
@echo off
echo This tool fixes keys after a major hardware change – such as a P2V migration

if %PROCESSOR_ARCHITECTURE% == x86 reg delete “HKLM\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent\Keys” /v binap /f
if %PROCESSOR_ARCHITECTURE% == x86 reg delete “HKLM\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent\Keys” /v binas /f
if %PROCESSOR_ARCHITECTURE% == x86 reg delete “HKLM\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent\Keys” /v binrs /f
if %PROCESSOR_ARCHITECTURE% == x86 reg delete “HKLM\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent\Keys” /v binsp /f

if %PROCESSOR_ARCHITECTURE% == AMD64 reg delete “HKLM\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Agent\Keys” /v binap /f
if %PROCESSOR_ARCHITECTURE% == AMD64 reg delete “HKLM\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Agent\Keys” /v binas /f
if %PROCESSOR_ARCHITECTURE% == AMD64 reg delete “HKLM\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Agent\Keys” /v binrs /f
if %PROCESSOR_ARCHITECTURE% == AMD64 reg delete “HKLM\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Agent\Keys” /v binsp /f

net stop McAfeeFramework
net start McAfeeFramework

if %PROCESSOR_ARCHITECTURE% == x86 “%ProgramFiles%\McAfee\Common Framework\CmdAgent.exe” -s -p
if %PROCESSOR_ARCHITECTURE% == AMD64 “%ProgramFiles(x86)%\McAfee\Common Framework\CmdAgent.exe” -s -p

reg delete “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” /v CPQTEAM /f

set devmgr_show_nonpresent_devices=1
start devmgmt.msc
[/cc]

To make things even easier, I have placed this script in an ISO image on my desktop. I can easily connect this ISO to the VM and access utilities even if my network connection is not connected.

Other utilities I keep in this ISO image are:

• HP Proliant Support Pack Cleaner – http://ctxadmtools.musumeci.com.ar/HPPSPCleaner/HPPSPCleaner11.html
• IBM Director Cleanup – http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5071462&brandind=5000016

A few days back I saw a twitter post from @maishsk which linked to this article:

http://technodrone.blogspot.com/2010/04/how-to-speed-up-your-powercli-queries.html

The article got me thinking about the difference between Get-VM and Get-View and I wanted to apply it to a script I’ve been using for a little while.  This is a pretty simple script that finds my virtual machines that have incorrect names — the host name inside the VM doesn’t match the name of the VM in the vCenter console.

Using the Get-VM cmdlet takes 148.7862461 seconds to find all of my virtual machines (excluding the templates):
[cc lang=”powershell”]$getvms = (Measure-Command {get-vm | where { $_.Guest.HostName -ne $NULL -AND $_.Guest.HostName -notmatch $_.Name } | select-object name, {$_.Guest.HostName}}).TotalSeconds[/cc]

Using the Get-View VirtualMachines cmdlet with a filter to exclude templates only takes 11.6853342 seconds:
[cc lang=”powershell”]$getviewf = (Measure-Command {get-view -viewtype virtualmachine -Filter @{“Config.Template”=”false”} | where { $_.Guest.HostName -ne $NULL -AND $_.Guest.HostName -notmatch $_.Name } | select-object name, {$_.Guest.HostName}}).TotalSeconds[/cc]

While either script does a better job than trying to compare these settings manually, this Get-View method shows a very significant savings!  Thanks for the suggestion @maishsk!

Just in case you only want the query to show VM’s with incorrect names, here you go:

[cc lang=”powershell”]get-view -viewtype virtualmachine -Filter @{“Config.Template”=”false”} | where { $_.Guest.HostName -ne $NULL -AND $_.Guest.HostName -notmatch $_.Name } | select-object name, {$_.Guest.HostName}[/cc]

In an earlier post I mentioned a script written by a co-worker to determine all of the non-thinprovisioned virtual machines.  This script is a follow-up to that, which allows actually uses storage vMotion to resolve the problems.  It is important to note that this script does not provide ANY error checking — if you try to move virtual machines to a datastore that does not have enough capacity you’ll be in trouble.  However, I have used this script to re-arrange many virtual machines and it was successful (I always verified I had enough target capacity before starting the script).
[cc lang=”powershell”]$dsView = Get-Datastore -Name “target-datastore” | Get-View -Property Name

Get-VM “vm-num1″,”vm-num2” | % {
$vmView = $_ | Get-View -Property Name
$spec = New-Object VMware.Vim.VirtualMachineRelocateSpec
$spec.datastore = $dsView.MoRef
$spec.transform = “sparse”
$vmView.RelocateVM($spec, $null)
}[/cc]

Another interesting PowerCLI script from today.  My proof of concept environment uses thin provisioned disks — this lets us have a lot more test machines than we really have disk space.   The other day we ran out of space — a new admin had been creating test machines for a project using oversized disks and thick-provisioning.  A coworker actually came up with this script to help find those disks so we could turn thin provisioning back on:

get-vm | get-view | %{
 
$name = $_.name
 
$_.Config.Hardware.Device | where {$_.GetType().Name -eq "VirtualDisk"} |  %{
 
if(!$_.Backing.ThinProvisioned){
 
"$name has a thick provisioned disk"
 
}
 
}
 
}