## Get-View to speed up things using regex

I was playing around with the get-view cmdlet and found something I didn’t know yet.

On the site there is an example

Get-View -ViewType VirtualMachine -Filter @{"Name" = "VM"}


Cool, let’s test that. Hey , why do I get 2 items returned?
I searched for a VM called “Test” and there returned 2 VM’s which are started with “Test”.

I didn’t know that, in the description of the filter object you see:

Specifies a hash of <name>-<value> pairs, where <name> represents the property value to test, and <value> represents a regex pattern the property must match. If more than one pair is present, all the patterns must match.

Ah…

So let’s throw some regex in then:

One way to tighten our patterns is to define a pattern that describes both the start and the end of the line using the special ^ (hat) and $(dollar sign) metacharacters. Maybe not the best option but it works fine. To do an exact match on “Test””we use : “^Test$

Now let’s start exact match on Test and do a reset of the VM:

(get-view -ViewType VirtualMachine -Filter @{"name"="^Test$"}).ResetVM()  Cool that works, I’m no regex expert, but the way mentioned above works, because the start..end of the line only exists of VM names. It would be nicer to use a word boundary so you capture the word only and not the line. So we can also use \bServername\b:  get-view -ViewType VirtualMachine -Filter @{"name"="\bTest\b"}  Both options work, but may come in handy for the future. So what I learned, the filter object can be ‘regexed’ ! ## PowerCLI: Show HBA Path Status *Updated* Because our storage team was doing some upgrades lately they asked if I could the check the storage path status. We have 2 FC HBA’s per server which are connected to a seperate FC switch. Storage normally upgrades 1 path then we check to be sure before starting to upgrade the other path. Got my inspiration from internet and credits go to them : https://jfrmilner.wordpress.com/2011/08/27/checking-for-dead-paths-on-hbas-with-powercli/ * Used the output as a starting point where I want to go. http://practical-admin.com/blog/powercli-show-hba-path-status/ * Pefect clean use of the get-view feature, only nasty part was the end $result += "{0},{1},{2},{3},{4}" -f $view.Name.Split(".")[0],$hba, $active,$dead, $standby } } ConvertFrom-Csv -Header "VMHost", "HBA", "Active", "Dead", "Standby" -InputObject$result | ft -AutoSize


Which I changed by creating a new object.

$row = "" | Select VMhost,HBA,Active,Dead$row.VMhost = $view.Name.Split(".")[0]$row.HBA = $hba$row.Active = $active$row.Dead = $dead$result += $row } }$result|ft -AutoSize


This object then can easily be exported to CSV/Table whatever you like. It also can be easy to for a wrap up like I made at the end.

$result |Measure-Object -Property Active,Dead -Sum|select property,sum|ft -AutoSize Especially in a larger environment you don’t have to keep scrolling to see where it failed, just look at the summary to see if you need to scroll up 🙂  cls function Check-DeadPaths{ <# .SYNOPSIS This function checks and reports path status .DESCRIPTION This function checks and reports path status .PARAMETER Outputfile Specify a output file, exported in CSV format. .EXAMPLE PS C:\> Check-DeadPaths -Outputfile "C:\temp\output.csv" .INPUTS System.String .OUTPUTS System.Collections.Hashtable #> [CmdletBinding( SupportsShouldProcess =$true, ConfirmImpact = "Low")]
[OutputType([Hashtable])]
param(
[Parameter(Mandatory = $false)] [string]$Outputfile
)
BEGIN {
try {
}
catch {
Throw
}
}
PROCESS {
try {
if ($pscmdlet.ShouldProcess){$views = Get-View -ViewType "HostSystem" -Property Name,Config.StorageDevice
$result = @() foreach ($view in $views | Sort-Object -Property Name) { Write-Host "Checking"$view.Name
$view.Config.StorageDevice.ScsiTopology.Adapter|Where-Object{$_.Adapter -like "*FibreChannelHba*" } | ForEach-Object{
$active,$standby,$dead = 0$key = $_.Adapter$wwn = $view.Config.StorageDevice.HostBusAdapter|Where-Object{$_.key -eq $key}$_.Target | ForEach-Object{
$_.Lun | ForEach-Object{$id = $_.ScsiLun$multipathInfo = $view.Config.StorageDevice.MultipathInfo.Lun | ?{$_.Lun -eq $id }$active = ([ARRAY]($multipathInfo.Path | ?{$_.PathState -like "active" })).Count
$standby = ([ARRAY]($multipathInfo.Path | ?{ $_.PathState -like "standby" })).Count$dead = ([ARRAY]($multipathInfo.Path | ?{$_.PathState -like "dead" })).Count
}
}
$row = "" | Select VMhost,HBA,PortWorldWideName,NodeWorldWideName,Active,Dead$row.VMhost = $view.Name.Split(".")[0]$row.HBA = $_.Adapter.Split("-")[2]$row.PortWorldWideName = "{0:X}" -f $wwn.PortWorldWideName$row.NodeWorldWideName = "{0:X}" -f $wwn.NodeWorldWideName$row.Active = $active$row.Dead = $dead$result += $row } } } } catch { [String]$returnMessage = "Failed to create Kibana dashboard for environment $Environment.rnScriptname: " +$_.InvocationInfo.ScriptName + "rnLine: " + $_.InvocationInfo.ScriptLineNumber + "rnError: " +$_.Exception.Message
}
$result|ft -AutoSize Write-Host "Total Wrap up:"$result |Measure-Object -Property Active,Dead -Sum|select property,sum|ft -AutoSize
if ($outputfile){$result|Export-Csv $outputfile -Confirm:$false -useculture -NoTypeInformation
}

END {
try {
return @{returnMessage = $returnMessage} } catch { Throw } } }  ## HP Power settings to maximize perfomance Below are some BIOS settings we set on our ESXi hosts, but also on other HP DL series servers. Everything is used for maximum performance, we don’t look for powersaving features. Or processor C-states which scale up/down the frequencies, this mostly has a negative impact on hard working machines. HP Power settings to maximize perfomance  Setting Value Description Intel Turbo Boost Technology Enabled Allows processors to make a transition to a frequency that is higher than its rated speed Thermal Configuration Optimal/Increased Cooling Use the one that provides the desired performance for the lowest power consumption HP Power Profile Maximum Performance Disables all power management options that may negatively affect performance HP Power Regulator HP Static High Performance Keeps processors in their maximum power/performance state Intel QPI Link Power Management Disabled Precludes placing unutilized QPI links into low power state Minimum Processor Idle Power Core State No C-States Precludes processor transitions into low power core C-States Minimum Processor Idle Power Package State No Package State Precludes processor transitions into low power package C-States Energy/Performance Bias Maximum Performance Configures processor subsystems for high performance/low latency Collaborative Power Control Disabled Precludes the OS from changing clock frequency DIMM Voltage Preference Optimized for Performance Runs DIMMs at a higher voltage if it increases performance Dynamic Power Capping Functionality Disabled This option allows for disabling System ROM Power Calibration during the boot process Doing so accelerates boot times but precludes enabling of a Dynamic Power Cap Memory Power Savings Mode Maximum Performance This option configures several memory parameters to optimize the memory subsystems performance and is configured to Balanced by default These are quite the main features to disable. References: http://www.vmware.com/files/pdf/techpaper/VMW-Tuning-Latency-Sensitive-Workloads.pdf http://h10032.www1.hp.com/ctg/Manual/c01804533.pdf ## ESXi Setting syslog and firewall settings with PowerCLI # Syslog and firewall configuration with PowerCLI ## Setting PowerCLI Due the arrival of some SIEM solution I needed to reconfigure ESXi hosts to not only point to our Kiwi Syslog server, but also to the appliance. So a good job for some PowerCLI I had some trouble using the set-VMHostSysLogServer as it didn’t seem to work as expected. It worked on 2 hosts which hadn’t any syslog configured, but somehow I couldn’t set all to$Null or to the new value, very strange. But I don’t give up and found the Set-VMHostAdvancedConfiguration cmdlet to set the syslog values on another way.

get-vmhost| Set-VMHostAdvancedConfiguration -NameValue @{'Syslog.global.logHost'='syslog'} -confirm:$false While testing I noted the message: This cmdlet is deprecated. Use New-AdvancedSetting, Set-AdvancedSetting, or Remove-AdvancedSetting instead. Mmm let’s have a look here: get-vmhost|select -first 1|get-advancedsetting -Name syslog* |select name,value|Ft -a Name Value —- —– Syslog.Remote.Port 514 Syslog.Remote.Hostname syslog Syslog.Local.DatastorePath [] /vmfs/volumes/4dd2476c-etc. Let’s try to set it Get-AdvancedSetting -Entity (get-vmhost|select -first 1) -Name Syslog.Remote.Hostname|Set-AdvancedSetting -Value syslog -confirm:$false

You also can set multiple values like:

Get-AdvancedSetting -Entity (get-vmhost|select -first 1) -Name Syslog.Remote.Hostname|Set-AdvancedSetting -Value syslog1,syslog2 -confirm:$false After setting the proper syslog setting it was necessary to open the syslog firewall ports on ESXi. To do this on all hosts, it can easily be done with the onelinerbelow using the Get-VMHostFirewallException cmdlet Get-VMHostFirewallException -VMHost (get-vmhost) -Name syslog|Set-VMHostFirewallException -Enabled:$True -Confirm:$false ## Warning: Failed to connect to the agentx master agent (hpilo:) # Warning: Failed to connect to the agentx master agent (hpilo:) ## Noticing While doing by adminstrative tasks, I was wandering through the syslogs and I noticed a system returning the message below every few minutes. hpHelper[14674]: Warning: Failed to connect to the agentx master agent (hpilo:) Mmmz let’s try to reboot the system, this was no solution. I checked the settings of the ILO board of this system with a similar system (both HP DL380 Gen8) and saw some differences. One system without the problems was set to “agentless management” the other had some SNMP settings. I removed the SNMP settings and put it to agentless like the host without problems. After that I restarted all the services to make sure it would reset the connection. To bad it didn’t work either. ## Solution With a little search I found this site. This triggered me..might not be the problem on ESX side, but maybe on ILO side. So I resetted the ILO board and so the connection reinitialized. The AgentX messages disappeared and the problem seems to be solved. ## Could not connect using the requested protocol PowerCLI ## Problem Suddenly (during a failover test) I noticed a script didn’t work anymore. The script I used connects directly to an ESX host. And I got the error below, somehow I never ever had this before and we used this script for a long time. So something changed, but when and why did this happen was still on my research list. After a google search for “requested protocol” error I found the solution Connect-VIServer : 22-3-2014 9:03:07 Connect-VIServer Could not connect using the requested protocol. At C:\Users\ee34028.adm\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1:361 char:42 +$currentConnection = Connect-VIServer <<<< $vcHost -Credential$cred
+ CategoryInfo : ObjectNotFound: (:) [Connect-VIServer], ViServerConnectionException
+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_ProtocolError,VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer

## Solution

To get rid of this problem there is a solution that sets the powerCLI configuration to “Use no proxy”

The solution is described in:
Connecting to the AutoDeploy server fails with the error: Could not connect using the requested protocol (2011395)

Open your powerCLI console as administrator (else you don’t have sufficient rights to edit this setting)
To show the current configuration use “Get-powerCLIconfiguration

C:\>Get-PowerCLIConfiguration

Proxy Policy Default Server
Mode
-------------------------       ---------------
UseSystemProxy      Single

As you can see it uses the system’s proxy. To change this use “Set-PowerCLIConfiguration -ProxyPolicy NoProxy -Confirm” to set the proxy settings to “NoProxy”
You can choose two proxy policies

C:\>Set-PowerCLIConfiguration -ProxyPolicy NoProxy -Confirm
Perform operation?
Performing operation 'Update vSphere PowerCLI configuration.'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
Proxy Policy Default Server
Mode
------------         ---------------
NoProxy              Single

## VMware : Converting IDE disks to SCSI

After migrating the linux environment from KVM to ESX (see my previous post how to do it). We noticed that the disks
where connected as IDE disks, therefor it wasn’t possible to (dynamicly) resize them or add more disks then 4 IDE slots (including CD-ROM)

It pretty easy to convert these to a SCSI disk, but it will require downtime.
Converting a virtual IDE disk to a virtual SCSI disk (1016192)

It’s recommendend for Windows machines to repair the MBR of the disk as adviced in the article above.
When encountering problems you could have a look at :
Repairing boot sector problems in Windows NT-based operating systems (1006556)

Luckily we tested it a few times in the Linux environment without encoutering problems (all VM’s are RedHat 6.4 or higher)

1) Turn off the VM
2) Locate the ESX host from the VM
3) Locate the datastores of the disks to edit
4) Turn on SSH on the ESX
5) Connect using SSH and go to the VM folder

# cd /vmfs/volumes/<datastore_name>/<vm_name>/


Now open the VMDK file using a VI editor like VI or nano for more information about VI/Nano
Editing files on an ESX host using vi or nano (1020302)
*Note: Nano is not available in ESXi. But can manually be installed

6) In this case we edit the TEST_PAT.vmdk file

# vi TEST_PAT.vmdk


When you look at the file you will see a ddb.adaptertype = “IDE” this is the value ESX uses to determine the adapter to use.In this case, when you add the VMDK using  “add new disk -> use existing disk” it will see IDE and add an IDE adapter.

So wee need to change this value

Specify one of these parameters: lsilogic or  buslogic .

This table shows the adapter type for the guest operating system:

 Guest Operating System Adapter Type Windows 2003, 2008, Vista lsilogic Windows NT, 2000, XP buslogic Linux lsilogic

In this case we chose the lsilogic

Change IDE to LSILOGIC and save the file.

Next go back to your virtual machine and remove the disks you edited (don’t remove it from your storage), so wisely chose “Remove from Virtual Machine”
It’s important not to remove the disk first before you start editing because the VMDK descriptor file doesn’t exist yet if the disk is not connected to a VM.

Apply the settings. Now go back to edit settings -> add -> Harddisk -> Use an existing virtual disk -> Browse to the location of the disk file and click next a few times.
As you notice it will display Disk adapter as SCSI now.

Thats it!

## Auto-update VMware tools installation fails?

Somehow we noticed a few machines where it was not possible to auto-update the VMware tools from vCenter. After a time-out of 30 minutes the task failed. Result, no VMware tools installed and a task that failed (according to vCenter) but a task keeps remaining on the ESXi host/VM.

We never encountered this issue, after looking through log files, eventvwr etc. I didn’t find a proper explanation. Somehow I suddenly got a clear moment and thought about looking in the advancedsettings from the VM because a while ago I changed the template settings according to our yearly hastle with the security baseline 🙂
Easy with powerCLI:

get-vm <vm>|Get-AdvancedSetting

Mmz I found a tools setting:

Name: isolation.tools.autoinstall.disable
Value:true

This just means that the auto-install is disabled. That explains why it won’t work automatically, and manually we didn’t encounter any issue.

Hah, this easily can be edited also with powerCLI.

get-vm <VM>|Get-AdvancedSetting -Name isolation.tools.autoinstall.disable|Set-AdvancedSetting -Value:$false -confirm:$false

DAMN!

I throw this script in our test cluster, but somehow not all machines can be edited. A little investigation leaded me to the fact that the machines which failed got a “Time-out VMware tools install task”

So what about killing the task, it was not possible through vCenter, I tried to restart the management agents on the host but that wasn’t a success also.

Then I came accross this VMware article :
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1038542

1. Run this command to identify the virtual machine ID:
# vim-cmd vmsvc/getallvms

You see an output similar to:

2256   testvm          [datastore] testvm/testvm.vmx              winNetStandardGuest       vmx-07
2. Note the ID of the virtual machine with the ongoing VMware Tools installation. In this example, the virtual machine ID is 2256.
3. Run this command to stop the VMware Tools installation:
# vim-cmd vmsvc/tools.cancelinstall <vm_ID>

Where <vm_ID> is the ID of the virtual machine noted in Step

Now the Tools upgrade task is killed, now it is possible again to vMotion, change advanced settings etc.

So now it’s possible to edit the settings. I started the script again and it went flawlessly. Next step is to try the VMware tools installation again.

I picked a machine, started install VMware tools through vCenter and waited….after 30 minutes again: TIME-OUT!
Mmmmm maybe we need to power-off/power-on the VM to pick the new setting. So again, cancelled task, checked setting. All OK.

Shutdown vmguest, power-on and reinstall VMware tools through vCenter this seems to be the magical combination.

To wrap it up:

– Cancel any running tasks on the ESX host/VM
– Change the isolation.tools.autoinstall.disable setting
– Power off/on the VM
– Reinstall VMware tools

Best is of course to change the setting while the machine is powered off.

Or just do a manual install 🙂

Last but not least I created a little script to retrieve the key, and if the key exists, and the value not equals  “true”, it sets the setting to


foreach ($VM in get-cluster *199* | Get-VM){$Setting = $VM|Get-AdvancedSetting -Name isolation.tools.autoinstall.disable|select name, value if ($Setting -ne $null){ if ($Setting.value -ne "false"){
$VM|Get-AdvancedSetting -Name isolation.tools.autoinstall.disable|Set-AdvancedSetting -Value:$false -Confirm:\$false
}
}
}



## VM import Failed to open disk scsi0:0

VM import Failed to open disk scsi0:0: Unsupported and/or invalid disk type 7. Did you forget to import the disk first?Unable to create virtual SCSI device for scsi0:0, Module DevicePowerOn power on failed.

I noticed this issue after we tried to import a VM created in VMware View in our ESXi 5.1 environment. When we tried to power on the machine the error message below appeared. This has something to do with the disk format.

In this example a disk of 100GB was created for the VM in VMware View. After enabling SSH on the ESXi host and looking on the datastore you’ll notice a vmdk of 27 GB.

/vmfs/volumes/4dc3d515-66b8d17d-49db-00237d54cab0/Windows 7 x64_1 # ls –l
<b>-rw-------    1 root     root     28533391360 May  8 12:58 Windows 7 x64_1-0-s001.vmdk</b>
-rw-------    1 root     root           537 May  8 13:56 Windows 7 x64_1-0.vmdk
-rw-------    1 root     root          8684 May  8 12:58 Windows 7 x64_1.nvram
-rw-------    1 root     root             0 May  8 12:58 Windows 7 x64_1.vmsd
-rw-------    1 root     root          2842 May 13 07:19 Windows 7 x64_1.vmx
-rw-------    1 root     root          3049 May 13 07:18 Windows 7 x64_1.vmxf
-rw-r--r--    1 root     root         42582 May 13 07:19 vmware.log
-rw-------    1 root     root         25730 May  8 12:00 vprintproxy.log


To resolve this, we need to re-import the disk with the right format (Zeroed Thick).
To convert the disk to zerothicked, use vmkfstools. See the example below.

/Windows 7 x64_I-work1 # <i>vmkfstools -i  "Windows 7 x64_I-work1-0.vmdk" -d zeroedthick "Windows 7 x64_I-work1.vmdk"

With this command we make a clone of the existing disk (Windows 7 x64_1-0.vmdk) to a new disk (Windows 7 x64_1.vmdk) with the proper diskformat (-d –diskformat [zeroedthick|thin|eagerzeroedthick]).

After the cloning is completed, you could re-import the newly created disk in your VM and start it. (Don’t forget to remove the old one :))

## Incorrect “Degraded status” on HP Array Controller

I tried and worked flawlessly, so for all of you with this error….go and donwload !

Fixes:

Recommended – HP recommends users update to this version at their earliest convenience.

The following fixes were added to this release:

• Smart Array Controller incorrectly reports Degraded status: Fixed issue where HP Insight Management WBEM Providers were incorrectly reporting a ‘Degraded’ status for the Smart Array Controllers. This caused VMware vSphere Management Console under Health Status category to display a ‘Warning’ Status (Yellow Exclamation) for the HP Smart Array Controllers.  HP System Insight Manager and Insight Control for vCenter and other users of the HP Insight Management WBEM Providers would also report the Smart Array Controller as ‘Degraded’.
• Smart Array physical drive incorrectly reports OK status: Fixed issue where HP Insight Management WBEM Providers were not correctly reporting a not-OK status for a removed drive connected to a Smart Array Controller. This caused HP System Insight Manager, VMware vSphere Management Console, Insight Control for vCenter and other users of the HP Insight Management WBEM Providers to report the physical drive as OK after it was removed.
• Server reports incorrect processor Model: Fixed issue where HP Insight Management WBEM Providers would report an incorrect Processor Model for ProLiant servers and blades. For example: “Intel(R) Family: Intel(R) Xeon(TM) 2.5GHz (x86 Family 179 Model 125 Stepping 7)”” is reported instead of the correct  “Intel(R) Family: Intel(R) Xeon(TM) 2.5GHz (x86 Family 179 Model 45 Stepping 7