View Planner 2.0 – Load-test your VMware View implementation
Introduction
View planner is a workload simulator for VMware View environments that can be used to simulate a number of desktop workers, to verify the sizing of a given VMware View environment. It can also be used to test the impact of a change in your VMware View production environment. I.e. what is the impact of adding 512mb RAM to all your desktops, adding an additional vCPU or ramping up the number of desktops?
View Planner 2.0 is the natural successor to RAWC, meaning that RAWC is now EOL.
View Planner is only available to certified VMware Partners or delivered as a service through VMware PSO. The software is available from Partner Central.
Documentation of the different aspects of View Planner is delivered as part of the download in PDF format. It’s highly advised to read through the entire document prior to setting up and running View Planner, to get a thorough understanding of the architecture and its different requirements.
For more advanced settings, internal details, performance gathering, and getting more expertise on ViewPlanner, this document provides some additional information. This will help you to get an even better understanding and experience in using View Planner.
Technical specifications and requirements
View Planner is deployed as an OVF appliance. It’s built on Linux Centos 5.x distribution and comes pre-configured with 2GB of memory and 1 vCPU.
The View Planner appliance orchestrates the different run scenarios, meaning that it’s in charge of powering on and off VMs used in testing, creating users in Active Directory, creates reporting on finished runs etc. Most of the logic in View Planner is implemented in Python and MySQL database is used to store the results.
It’s controlled using a web-interface build into the appliance. Active Directory and View Connection servers are controlled using agents, which need to be installed on those systems. They have some very strict requirements for configuration of the underlying OS and services. More on these requirements and the impact it has on planning later in this article.
As of version 2.0, View Planner supports the following operating systems and software versions:
- Windows Server 2003 R2 32bit SP2
- This is required for both Active Directory Domain Controller and View Connection Server
- vCenter can be any version 4.x release, running on any supported Windows Server OS.
- Refer to the official VMware documentation for supported setup.
- VMware View 4.5/4.6 32bit. This in turn implies:
- View Composer 2.5/2.6
- View Agent 4.5/4.6 (32bit)
- View Client 4.5/4.6 (32bit)
- Windows XP SP3 32bit en/us (No MUI or localized versions are officially supported)
- Windows 7 Enterprise 32bit/x64 en/us (No localized versions are officially supported)
View Planner 2.0 does not support the PCoIP Security Gateway feature. This will be supported in a future release of View Planner.
All the above requirements should be followed 100% as there are a lot of custom changes required on the underlying OS. For all of those settings, please refer to the documentation included with the View Planner 2.0 download. Following the desktop and server build process is especially important.
Below is the architectural overview of a View Planner implementation. This also shows a logical overview of the required components as outlined above.
Planning to setup and run View Planner
View Planner 2.0 is best run in a totally isolated environment, not having any hooks into your production environment. By that I mean ESXi hosts being managed by a separate vCenter server, in an isolated Active Directory using a dedicated View Connection server/s. You are looking at the following server roles for having an optimal setup:
- Active Directory Domain Controller
- 1vCPU, 2GB of memory
- vCenter server
- 4 vCPU, 8GB of memory. Set TomCat server memory to 2048MB and Initial Memory to 1024MB.
- SQL Server
- 2vCPU, 8GB of memory
- View Connection server
- 2 vCPU, 4GB of memory
- View Planner 2.0 appliance
- Default settings
The above numbers are from a 1000+ VM run with 7 ESXi 4.1 hosts, 32Cores, 256GB of memory each.
If you are planning 500+ VM tests I would strongly recommend a dedicated SQL server (check VMware View 4.5/4.6 documentation for supported SQL versions) since the vCenter will already have its work cut out for it running View Composer as well.
Desktops should be built as per instructions in the View Planner 2.0 documentation. Be aware that the settings described in the documentation are only available after doing a full Windows update on top of Windows XP SP3 and your Windows Server 2003 R2 32bit servers. This includes Internet Explorer 8.0 as well, since the options described in the documentation are only available in IE 8.0+.
Office 2007 might prove to be an issue due to it requiring online activation, depending on what kind of activation key/version you have. Make sure to test the desktop image as described in the View Planner Documentation, so you can verify that all the Office 2007 applications run without requiring any user interaction. This test workload profile can also be used later on, if you make changes in the infrastructure, to verify everything is still working as planned.
Gathering performance statistics
View Planner does not give you any direct numbers when it comes to performance statistics. It will create a report showing the latencies for each operation in the different workloads within the desktop VMs. This means that you will have to setup some kind of performance monitoring solution prior to starting the workloads.
There are a couple of different approaches to setting this up, so I have listed some of the available solutions, and things to consider no matter what solution you end up using.
- Make sure that all the places you are collecting statistics from are in time sync. Be it NAS/SAN, Network switches, hosts, desktops, vCenter etc.
- Raise the statistics level to 3 in vCenter. Make sure to account for the disk-space requirements in the sizing of the SQL server used.
- Change the date and time settings on the View Planner appliance to match your timezone and summer/winter-time.
- The following article describes how this can be done on CentOS - http://www.cyberciti.biz/faq/howto-linux-unix-change-setup-timezone-tz-variable
- Depending on your storage and network vendor, have the correct tools and monitoring solution in place before starting the workloads.
The following lists some of the tools you can use to collect performance data.
- vCenter statistics
- esxtop/resxtop running in batch mode
- vCenter Operations Standard 1.0.1 (60 day trial)
- Xangati VDI Dashboard
- Liquidware Labs Stratusphere
vCenter performance statistics will go a long way but might not be enough. vCenter does roll-up on the data, meaning that after a given period of time you might not be able to get the granularity you where after. Please read the following article to get a better understanding of how this works: http://communities.vmware.com/docs/DOC-5230
Esxtop/resxtop can collect all the information you could ever want, but post-processing and analyzing that information is not an easy task. You are left with the task of adding values together, looking across multiple hosts to get the complete picture, and you are left doing this with tools like perfmon, esxplot or Excel spreadsheets.
vCenter Operations solve some of those issues, by being more granular and keeping statistics without doing roll-up on the data. vCenter Operations also allows easier access to the collected data, and the possibility of looking at the data from levels not easily available from vCenter statistics.
If testing on only 1 or maybe 2 hosts, esxtop might prove efficient, in multi host environments I would recommend using vCenter Operations Standard, since it gives you the best overview.
Xangati or Stratusphere require additional time and knowledge to configure. They will in some cases give you more in-depth performance statistics, especially if you are interested in PCoIP performance figures.
Luc Dekens has a great series about vCenter performance statistics using PowerCLI. This is a valuable resource if you want to do custom report after your runs.
Some key things to know before starting a View Planner project
- View Planner does not support multiple datacenters or vCenters
- Client VMs can however be deployed using linked clones to a separate cluster within the same vCenter server, to avoid them sharing hosts with the desktops.
- Office 2007 registration can be an issue. Test and verify the activation (MAK or KMS preferably) before deploying.
- All hosts need (preferably) to be taken out of their current context. I.e. the vCenter they might already be in for View Planner to have full control of the hosts.
- This also means that these tests are best run before production and not while already in production.
- Account enough time.
- Building the master images takes time, and so does building the required servers and testing everything. Each run takes 4-8 hours, and provisioning 1000+ VMs takes time as well. Within 3-5 days it should be possible to set everything up, and have the first run working. If you are planning for multiple different runs and workloads, account for the provisioning time, and the ramp-up time (This is described in more details in the View Planner documentation). View Planner powers on 4 VMs at a time, then sleeps for 60 seconds to avoid boot storm.
- Make sure to run initial tests with the desktop/client image to save time if errors show up. Don’t start of with 500+ VM provisioning assuming everything works. Chances are it doesn’t.
- You cannot use the {n} or other custom characters when provisioning using View to make your VMs have unique names. Just type the name and let View Composer extend these names with numbers.
- Using custom characters will make View Planner will fail once it tries to locate the VMs in the vCenter inventory using a prefix.
- Passive runs can do 4:1 (8:1 if client is configured with a min of 1GB RAM)
- You cannot use the master image directly from the customer’s production environment.
- View Planner (officially) only works with the applications specified in the documentation.
If testing the capacity of an entire View Block, remember to account for the clients as well. If you are faced with a typical View design concept like the one pictured below, and customer requires a View Planner run that will stress the blocks 100% based on sizing, you need to account for the client workloads. Since View Planner cannot work across datacenters or multiple vCenter servers, the easiest way is to add in hosts under the same vCenter in a second cluster that will run the clients. This is pictured below with a View design of 2 blocks sized for different workloads.
The above shows what could be a typical View Block design. If the customer has requested that “View Block 1” is load tested 100%, you could restructure the vCenter and Cluster design to look like the picture below.
This would allow you to test “View Block 1” with 1024 desktops (Not customer master-image desktops, but View Planner desktops) using only 256 client VMs.
There is also the option of running in “Local Mode” which does not require clients; it just uses AutoIt scripts inside the desktop images to run the workloads. This can be used if you do not have spare capacity (hosts) to run the client workloads, or if statistics for PCoIP/RDP usage on the network is not required.
Only Passive Mode or Remote Mode will give you performance statistics for the network as well.
Running the workloads
If you encounter any errors while doing runs, entitlement, creating VMs etc., you can try to restart the services involved. For everything to come back in the correct order, you should do it following the steps below:
- Terminate the “server.pyc” process on both Domain Controller and View Connection Server.
- Make whatever changes required and start her “server.pyc” process on both Domain Controller and View Connection server again by running:
python server.pyc
This will re-connect the agents to the View Planner appliance - Log into the View Planner appliance using the root account and run the following command:
service vdiappd restart - This will restart the View Planner service, while still maintaining the connections made in step 2 above.
Restarting the vdiappd service will clear your current error.log. Backup the file before restarting the service if you need the error.log for troubleshooting purposes later on.
Monitoring the runs using the web-interface is not the most efficient way, since it populates a form with the content of /root/ViewPlanner/error.log and automatically updates it.
If you SSH into the appliance as root you can run the following command to see what’s going on in the error.log:
tail –f /root/ViewPlanner/error.log
You can also run grep, cat etc. commands if you are looking for specifics in the logfile.
If you experience problems with connecting the AD or View Connection servers to the harness (View Planner) you can run the following on either of those servers:
python listener.pyc
That will give you connectivity information, and show if there are any errors.
When doing provisioning of the desktops/clients I would advice to stay within the 512 VMs per pool that’s currently the maximum supported in View 4.x and 5.0, unless the customer has specific requirements for testing more than 512.
You can still test more than 512 desktops in a run, by using naming conventions that allows the View Planner the right mapping of the prefix. If i.e. testing for 1500 desktops, you could use the following naming for the pools:
deskP1
deskP2
deskP3
This would allow you to use “desk” as a prefix in View Planner when setting up a run, to match all the combined 1500 desktops in all 3 pools.
View Planner is a great service tool that can actually prove if the solution designed can handle the load. Even though it’s not the customer specific desktop images being run, it still puts a lot of random stress into your environment, and its an overall great way of validating the platform.
IPMI settings using PowerCLI – and some HP iLO specifics
A couple of weeks ago i was tasked with automating configuration of 64 ESXi hosts - one of these configurations being setting IPMI settings for each host, so that DPM could be of use (Yes - there are actually some customers using it...)
Not wanting to do this manually, i googled and found this VMware communities post that showed PowerCLI code defining IPMI settings for a host. (All credit for the script goes to Mike Laverick and sradnidge) The reason for this post is just to show how you can take this one step further, by packing the code into foreach loops and reading from a CSV file.
All the host information with this particular customer was kept in a Excel spreadsheet, or rather a CSV file. This allowed is to keep all "non-vCenter accesible" information in a format that we could query and use for scripting purposes. This was also used for defining the datastore used for scratchlocation, UUID for PXE boot/install, vmk IP settings etc. More on this in another post.
Here is an example of how this CSV could look (the naming in this example will work directly with the script)
Hostname,iLOIP,iLOMAC esxhost01,192.168.234.101,76:4B:E1:0F:6F:07 esxhost02,192.168.234.101,76:5B:E1:0C:EC:9E esxhost03,192.168.234.101,F7:49:AA:AB:F0:84 esxhost04,192.168.234.101,F7:49:AA:AB:71:A0 esxhost05,192.168.234.101,F7:49:AA:AB:59:9D
Now for some of the HP specifics of this post. iLO IP and iLO MAC address was obtained using hponcfg - a CLI tool that can execute code through either Onboard Administrator (OA)or as a Windows/Linux executable that can be obtained from HPs website.
I would recommend to use the version included with OA since it's already there, and only needs a tftp server to execute the XML scripts from.
Samples for how to use the hponcfg can be downloaded by following this link. It's a package of .XML files that shows how to run different commands. Everything from getting network configuration, resetting passwords and creating new users are detailed.
The scripts i used was "Get_Networking.XML" and "Add_User.XML". The first to obtain networking/iLO information across an entire chassis, the second to create a user which could only manage the power settings of each host, so we did not have to use an account that had to many privileges - a service account for the IPMI settings.
With the iLO IP, iLO MAC and a newly created user that could manage the power settings of the HP blades it was only to update the script:
Add-PSSnapin vmware.VimAutomation.core -ErrorAction SilentlyContinue
Connect-VIserver -Server your.vcenter.server
$VMHosts = @(Import-Csv "C:\scripts\host-info.csv")
$IPMIUser = "dpmuser"
$IPMIPass = "dpmpass"
foreach ($VMhost in $VMHosts) {
$esxMoRef = get-vmhost $VMHost.Hostname | % {Get-View $_.Id}
$IpmiInfo = New-Object Vmware.Vim.HostIpmiInfo
$IpmiInfo.BmcIpAddress = $VMHost.iLOIP
$IpmiInfo.BmcMacAddress = $VMHost.iLOMAC
$IpmiInfo.Login = $IPMIUser
$IpmiInfo.Password = $IPMIPass
$esxMoRef.UpdateIpmi($IpmiInfo)
}
You need to change the Connect-VIserver, the location of your .CSV file and the username/password for the IPMI connection to suit your environment.
Download the script here (rename to .ps1) Set-IPMIHostSettings
Get NUMA information across hosts using PowerCLI
I have seen a couple of times that NUMA scheduling has had quite a large impact on performance in vSphere environments. Especially with a Wide-VM with a large amount of what is called remote memory. That kind of information can be quite cumbersome to get, but this script will show it on a per cluster level, and in the output color-code what VMs might suffer from bad memory locality. It also shows some basic information for the hosts, and which NUMA node a VM is currently running on. The script is a “snapshot” meaning that it does not take history into account. When you run the script it simply loops through all the hosts and collects the data at that point in time.
To see an example of the output I have uploaded a sample file here.
For more information on NUMA and how it works, please read the following articles over at Frank Dennemans blog:
These are all superb articles that describe how NUMA works and what to be aware of. These are worth a read even if you have already been through them.
I tried to do some things different with this script. I’m a sucker for “pretty-output” and I thought that this script would be a good candidate to try something more than just CLI or CSV output. Having worked some with XML and XSLT (XPATH on top) I made this script output raw XML using the “ConvertTo-XML” cmdlet and then did all the presentation changes and logic using XSLT and XPATH. In my view this is a great way to show of data and make it interactive, since it has the potential to use web-based services - I use Google Chart API for the graphs in the server info, and SortTable JavaScript for sorting the data – which allows for more than just text output, and does not require the user to have Excel or some other program that can present CSV as more than just text. On top of this the XML file is not changed in anyway (the XSL file takes care of the presentation), and can still be used for input in Excel or whatever program you would wish to use for altering the output.
This does however have some drawbacks as well. Since web-based components are used it requires internet access to draw the charts and for being able to sort the data. It also comes with an extra file – numainfo.XSL – which holds all the formatting of the data.
If you find this useful I would be happy to share some information on how to use the PowerShell XML output with XSLT and XPATH. Please let me know what you think in the comments.
Click here to download the file containing both the .ps1 file and the .xsl. The output XML file will be placed in the path where you execute Get-NUMAinfo.ps1 from. The numainfo.xsl should also be placed in the same folder as the output numainfo.xml file.
The script prompts for all required information except the vCenter server to connect to. This can be changed on line 18 in the script to suit your environment. I have uploaded it as a ZIP. The ZIP file contains the .ps1 file and the .xsl file which is used for presentation.
And a big thanks to Stuart Langridge over at http://www.kryogenix.org for making the excellent SortTable.JS publicly available.
############################################################################
# Scriptname: Get-NUMAinfo.ps1
# Description: Shows NUMA info across hosts in a cluster
# By: Rasmus Jensen (www.vpeeling.com)
#
# Usage:
# Script will run without any arguments. The only thing to be changed is
# the variable $vCenter on line 18 of the script, to point to your vCenter.
# The script prompts for username and password for vCenter, and an account
# with root permissions to every host in the chosen cluster.
# If you dont want the script to prompt each time, just change all the
# "read-host" into variables in the script.
# If the script fails, remove the "Clear-Host" commands for better debug
# options.
############################################################################
Add-PSSnapin vmware.VimAutomation.core -ErrorAction SilentlyContinue
$vCenter = "my-vc-hostname"
$path = "$pwd\numainfoTMP.xml"
Clear-Host
# Defines username and passwords for vCenter and host logins
$vCLogin = read-host "Enter vCenter admin account"
$vCPass = read-host -AsSecureString "Enter password for vCenter admin account"
Write-Host ""
Write-Host ""
$HostLogin = read-host "Enter account name with root priveligies on your ESX hosts"
$HostPass = read-host -AsSecureString "Enter password for the accountname specified above"
# Takes provided credentials above to PSCredential for use with host and vCenter login
$HostCred = New-Object System.Management.Automation.PSCredential -ArgumentList $HostLogin,$HostPass
$vCCred = New-Object System.Management.Automation.PSCredential -ArgumentList $vCLogin,$vCPass
# Connect to vCenter...
Connect-VIServer $vCenter -Credential $vCCred
# Creates a list of clusters in the specified vCenter server
$clusters = @(Get-Cluster)
$i = 0
# variable for the Write-Progress
$wi = 0
Clear-Host
Write-Host ""
Write-Host ""
# Shows a list of clusters.
Foreach ($cluster in $clusters) {
Write-Host "[" -nonewline; Write-Host $i -ForegroundColor Yellow -nonewline; Write-Host "]" $cluster.Name
$i++
}
Write-Host `n
$clusterChooser = Read-Host "Choose from the list above, the Cluster you would like NUMA statistics for"
$clusterChosen = $clusters[$clusterChooser]
Clear-Host
# Defines the number of servers in the cluster. Used for Write-Progress
$l = (Get-Cluster $clusterChosen | get-vmhost | select Name | sort Name).Length
$myCol = @()
foreach ($esxhost in (Get-Cluster $clusterChosen | get-vmhost | select Name | sort Name)) {
Write-Progress -Activity "Getting NUMA stats..." -Status "Host: $wi of $l" -PercentComplete (100*$wi/$l)
Connect-VIserver -Server $esxhost.Name -Credential $HostCred
# Gets esxtop data for each host
$esxtopData = Get-EsxTop -CounterName SchedGroup | SELECT GroupID, IsVM, VMName, HomeNodes, NumOfBalanceMigrations, RemoteMemoryInKB, LocalMemoryInKB, LocalityPct, Server | where {$_.isVM -eq "true"}
$PCPU = Get-EsxTop -CounterName PCPU
$PMEM = Get-EsxTop -CounterName PMEM
$NUMASchedDist = @(foreach ($VMN in $esxtopData) {$VMN.HomeNodes}) | group
$NUMANodeCount = @(foreach ($NUMANode in Get-EsxTop -CounterName NUMANode) {$NUMANode.NodeID})
$myNodes = @()
$i = 0
# Fills in the array with data
$myObj = "" | SELECT Host, NumOfNUMANodes, NumOfCores, PhysicalMemInGB, FreeMeminGB, numVMs, IsHost, VMsPrNode
$myObj."Host" = $PCPU.Server
$myObj."NumOfNUMANodes" = $PMEM.NumOfNUMANodes
$myObj."NumOfCores" = $PCPU.NumOfCores
$myObj."PhysicalMemInGB" = [math]::Round(($PMEM.PhysicalMemInKB / 1MB),0)
$myObj."FreeMeminGB" = [math]::Round(($PMEM.FreeMemInKB / 1MB),0)
$myObj."numVMs" = $numVMs = $esxtopData.Count
$myObj."IsHost" = "True"
$myObj."VMsPrNode" = $myNodes
$myCol += $myObj
$wi++
Disconnect-VIServer -Server $esxhost.Name -Confirm:$false
$esxData += $esxtopData
}
# inserts the custom XSL file into the XML output
$replace = "<?xml version=""1.0""?><?xml-stylesheet type=""text/xsl"" href=""numainfo.xsl""?>"
$esxData += $myCol
($esxData | convertto-xml -NotypeInformation).Save($path)
# Saves the edited version of the XML to current path.
.{
$replace
Get-Content numainfoTMP.xml | Select-Object -Skip 1
} |
Set-Content numainfo.xml
Remove-Item .\numainfoTMP.xml
vMA 4.1 and vilogger with Active Directory authentication
vMA and it's vilogger feature is great, and configuration of this has been covered in great detail over at Simon Longs blog. While setting this up for a customer that used Active Directory (AD) authentication (adauth), i ran into a few issues.
Normally everything on vMA is executed on either root/admin context (the vi-admin account) or user context (the vi-user account). These 2 accounts are created on each ESX/ESXi host when you add it as a target on the vMA. When using AD authentication against a vMA target, you (funny enough) authenticate using Active Directory.
This works as you would expect, but when using vilogger with AD targets the vMA requires something called "Unattended Authentication".
Unattended Authentication means that vi-admin executes "on behalf" of the AD user that added the server using vifp. It does that execute "on behalf" using something called a keytab file. A keytab file holds a given AD users username and password in non-cleartext format (not sure what kind of hashing/encryption it uses).
I have tried to show how that works below, and what the flow is when vilogger commands are executed from vMA, against an adauth added target.
The vSphere Management Assistance Guide 4.1 talks about this on page 15. I have tried to outline the entire process below.
Before you start the keytab creation and run any vMA commands, there are a few requirements:
- Configure ESX/ESXi/vMA to use the same time-source (Also configure for UTC timezone if using ESXi)
- Your ESX/ESXi hosts must be joined to the same Active Directory as the vMA.
- Authorize "ESX Admins" group or another AD group admin rights for all your hosts.
- Validate that you can login to your ESX/ESXi hosts using AD authentication.
- Validate that you can login to your vMA using AD authentication, and execute using passthroughauth by running:
vicfg-dns --server host.your.domain --passthroughauth - Download ktpass.exe to run from a Windows Server 2003 system.
I would also recommend that you create an account for adding the hosts using adauth. This makes it easier to maintain since you only need one keytab file, and need only one script described in the vMA 4.1 documentation, (Page 15, item 5) for requesting new tickets from Domain Controllers.
After the all the above steps pass you can create the keytab file using the following command:
ktpass.exe /out aduser.keytab /princ aduser@your.domain.com /pass yourPassword /ptype KRB5_NT_PRINCIPAL -mapuser DOMAIN\ADUSER
- aduser = the user who added the target on vMA
- your.domain.com = FQDN of your AD domain
- yourPassword = password of the adduser. You cannot specify * as described in the Microsoft ktpass.exe documentation. Password needs to be specified on the command line for the keytab file to be valid.
- DOMAIN\ADUSER = your NetBIOS domain and AD username.
Log in to vMA as vi-admin and add servers using adauth (You need to use double backslash or else the command will fail):
sudo vifp addserver host.your.domain --authpolicy adauth --username DOMAIN\\USERNAME
As vi-admin enable vilogger for your ESXi targets:
sudo vilogger enable --server host.your.domain
This command will start the workflow depicted above, and will also create the AD users home folder (/home/local/DOMAIN/username) where you will copy the keytab file to.
Upload the keytab file to the AD users homefolder. I.e. if your AD username is vmalog place the file in /home/local/DOMAIN/vmalog.
You should upload the file using the AD user. This is to make sure that the user has the right set of permissions to the file.
Now, as described on the vMA documentation, create a file called kticket-renew in the folder /etc/cron.hourly with the following content:
#!/bin/sh
su - DOMAIN\\USERNAME -c '/usr/kerberos/bin/kinit -k -t /home/local/DOMAIN/username/username.keytab username'
This will request a new ticket for your AD user from your Domain Controller(s) every hour, so the vilogger can continue to gather log files from your hosts.
vCenter log files and advanced settings
While clicking around in my test lab I noticed that some stuff I had manually put into the vpxd.cfg file was visible within the vCenter server advanced settings. In particular it was settings for vCenter log file directory, max file size and number of log files (rotation).
These are all settings that have been well described (over at yellow-bricks.com) and I always thought these settings should be manually added to the vpxd.cfg file. This is not the case since they can just as easily (actually I think it's easier this way) be added using advanced settings from the vSphere client.
The lines you want to add to the advanced settings are the following:
- config.log.directory
- config.log.maxFileSize
- config.log.maxFileNum
Here is an example of how this could look:
The above settings would save 40 log files, and have a size of 20MB.
So there you have it. No more manual vpxd.cfg editing. I'm thinking I'm the only one who haven't figured this out until now, so this might just be more of a kind reminder to myself 
Check VMware View 4.x pool provisioning status
If you have automatic provisioning enabled for any of your desktop pools, together with the "Stop provisioning on error" option, the desktop pool provisioning will be disabled, if the View Composer encounters any errors.
At current it is not possible to get any alerts if this happens - hence this script. It checks against the ADAM instance on the specified View Connection server if any desktop pools are disabled. If it encounters any pools with status "disabled" it sends an email and/or writes to the Windows event viewer.
If you would like the script to trigger an event, un-comment "Write-Eventlog" at the bottom of the script.
The script is meant to be scheduled (every 5 or 10 minutes should be appropriate). It only triggers email or event logs the first time the pool is disabled. This is to avoid getting an email every 5 or 10 minutes.
To schedule a PowerShell script add the following command to a .bat file, and use Windows Scheduler:
powershell -command "& 'MyScript.ps1' "
If you have any desktop pools you would like to exclude from this check, they can be written to the "pools-excluded.txt" file. This file is created the first time you run the script. Enter one desktop pool per line.
For additional info on how to use the script, please read the instructions included.
############################################################################
# Scriptname: VMWView-DPStatus.ps1
# Description: Checks against ADAM for Desktop Pool provisioning status
# By: Rasmus Jensen
#
# Usage:
# Script can be schedules to run every 5 or 10 minutes or whatever timeframe fits.
# if there are any Desktop Pools you want to exclude in the check, specify
# the Desktop Pools ID in the pools-exclude.txt file. It HAS to be the ID, not display name.
# Enter one Desktop Pool ID pr. line. The Desktop Pool ID can be retrieved from
# the View Admin web-interface
#
# Fill out the 4 values according to your installation:
# $viewServer - The View Connection Server you want to check against
# $smtpServer - The SMTP server you want to use for sending mails
# $MailTo - The mail you want to send status to
# $Mailfrom - The from address
############################################################################
# Defines log and txt files used in the script. It not exists; creates them. DONT CHANGE ANYTHING HERE.
$tmpLogFile = $MyInvocation.MyCommand.path
$LogFile = $tmpLogFile.Substring(0,$tmpLogFile.Length - 4) + ".log"
if (!((Test-Path $LogFile) -eq $true)) {Out-File -Encoding Default -FilePath $LogFile}
$ExcludeFile = ".\pools-excluded.txt"
if (!((Test-Path $ExcludeFile) -eq $true)) {Out-File -Encoding Default -FilePath $ExcludeFile}
$DisabledFile = ".\pools-disabled.txt"
if (!((Test-Path $DisabledFile) -eq $true)) {Out-File -Encoding Default -FilePath $DisabledFile}
$ExcludedPools = @(Get-Content -Path $ExcludeFile)
$DisabledPools = @(Get-Content -Path $DisabledFile)
# Defines variables used in the script
$ViewServer = "VIEWSERVER"
$SMTPServer = "SMTPSERVER"
$MailTo = "MAIL@TO.COM"
$MailFrom = "MAIL@FROM.com"
# Defines function for writing to logfile
function Write-Log($Msg){
$date = Get-Date -format dd.MM.yyyy
$time = Get-Date -format HH:mm:ss
Add-Content -Path $LogFile -Value ($date + " " + $time + " " + $Msg)
}
# Specify the LDAP path to bind to
$LDAPPath = 'LDAP://' + $viewServer + ':389/OU=Server Groups,DC=vdi,DC=vmware,DC=int'
$LDAPEntry = New-Object DirectoryServices.DirectoryEntry $LDAPPath
# Create a selector and start searching from the path specified in $LDAPPath
$Selector = New-Object DirectoryServices.DirectorySearcher
$Selector.SearchRoot = $LDAPEntry
# Run the FindAll() method and limit to only return what corresponds to Desktop Pools in VMware View
$RSPools = $Selector.FindAll() | where {$_.Properties.objectcategory -match "CN=pae-ServerPool"}
# Loop thrue each desktop pool found on the above $RSPools
foreach ($RSPool in $RSPools) {
$attribute = $RSPool.Properties
# Define what value we are looking for
$value = 'pae-vmprovenabled'
$ProvStatus = $attribute.$value
if ($ProvStatus -eq "1") {
# Nothing to see here
if ($DisabledPools -match $attribute.name) {
$erdis = (Get-Content $DisabledFile) | where {$_ -notmatch $attribute.name} | Out-File -Encoding Default -FilePath $DisabledFile
}
}
else {
# Check if the desktop pool is present in the excluded list
If ($ExcludedPools -match $attribute.name) {
# Nothing to see here either...
}
# Check if the desktop pool has already been marked as being disabled. This not to spam with mails/event. Log file is still written
elseif ($DisabledPools -match $attribute.name) {
}
# Write that the desktop pool has changed status to disabled since last check
else {
$errMessage = "
The following Desktop Pools have provisioning disabled:
Desktop Pool: $($attribute.name)
Provisioning status: $($ProvStatus)"
Write-Log -Msg $errMessage
Add-Content -Path $DisabledFile -Value $($attribute.name)
# Send mail - one pr. pool disabled.
Send-MailMessage -to $MailTo -from $MailFrom -subject "Disabled: $($attribute.name)" -body $($errMessage) -smtpServer $smtpServer
# Write event to eventlog, Event is written as PowerShell to Windows Powershell log.
# Write-Eventlog -logname 'Windows PowerShell' -source PowerShell -eventID 622 -EntryType Warning -message $($errMessage)
}
}
}
Download script: VMWView-DPStatus (rename to .ps1)
vSphere Client arguments – defining servers and credentials
This is more of a reminder to myself, since i can never remember the argument for passing on credentials to the vSphere client. So here are all the arguments available for VpxClient.exe:
-passthroughAuth = carries on currently logged on user credentials (use in conjunction with -s)
-s = server name
-u = username
-p = password
Here are a few examples:
"VpxClient.exe" -s esx01.company.com-u root -p MyPassword
"VpxClient.exe" -s esx01.company.com -passthroughAuth
The above can be used together with my script "Create vSphere Client shortcuts based on recent connections" so you can specify username//password for the shortcut it creates.
Script: Create vSphere Client shortcuts based on recent connections
The vSphere client holds a list of the servers you recently connected to, be it ESX hosts or vCenter servers. This list is kept in the registry. This small script loops through all your recent connections and creates a vSphere Client (vpxClient.exe) shortcut for each.
I had a lot of connections and wanted to save them as shortcuts in a folder. I then added that folder as a toolbar to my Windows taskbar for easier access. That gives me easy access to different environments. It looks like this:
The script needs to know the exact path to your vpxClient.exe ($vpxClientPath, line 02) file and the folder ($shortcutPath, line 05) to where you want to save the shortcuts. The script uses the default vSphere Client installation path for a x64 based system, and saves the shortcuts to a folder called Toolbars\vSphere on the currently logged on users desktop.
# Type in the complete path yo your vSphere client executable.
$vpxClientPath = "C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe"
# Type in the complete path to where you want the shortcuts placed
$shortcutPath = "$home\Desktop\Toolbars\vSphere"
# Get the parrent path for the RecentConnections key
$recentConnections = Get-ItemProperty registry::"HKEY_CURRENT_USER\Software\VMware\VMware Infrastructure Client\Preferences"
# Split the content of "RecentConnections" and create an array with the entries
$arrRecentConnections = @(($recentConnections.RecentConnections).Split(","))
# Create Wscript.Shell object for creating shortcuts
$wshshell = New-Object -ComObject WScript.Shell
# Loops thrue the array, and creates a shortcut for each entry
$i = 0
$l = $arrRecentConnections.Length
foreach ($recentConnection in $arrRecentConnections) {
$shortcut = $wshshell.CreateShortcut("$shortcutPath\$recentConnection.lnk")
$shortcut.TargetPath = $vpxClientPath
$shortcut.Arguments = "-s $recentConnection"
$shortcut.Save()
$progress = [math]::round(100*$i/$l, 0)
Write-Progress -Activity "Creating shortcuts..." -PercentComplete $progress -CurrentOperation "$progress% complete" -Status "Creating shortcut: $i of $l"
$i++
}
Script: Create PuTTY entries from vCenter or CSV
A lot of time i find myself in the need of logging into ESX servers using SSH. I use PuTTY for that which works just fine. But when you go to different environments on a regular basis, adding all those hosts IP/names manually takes time and are subject for human error. (not to mention its plain old boring) That is where this PowerShell script comes in handy.
The script creates PuTTY sessions with settings based on whatever PuTTY sessions you have already defined. This means that prior to running this script you need at least 1 saved and configured session. The script then lists all your saved sessions for you to chose one to serve as a template, which allow you to have whatever custom settings your prefer serve as the basis for the sessions this script creates.
It works with 2 types of input: CSV or vCenter. You can change between the 2 by changing the $srcInput to either vCenter or CSV directly in the script. (Line 06 in the script below)
If you chose vCenter remember to change the $vCenter value (line 09) to fit whatever vCenter server you want to connect to. If using CSV change the $csvFile (line 08) to point to your .csv file containing a list of servers you would like to add.
The CSV file needs to contain one column name of the value name. Below is an example of a .csv file that would work.
name
esx01.domain.com
esx02.domain.com
esx03.domain.com
esx04.domain.com
# Loads PowerCLI snapin
Add-PSSnapin vmware.VimAutomation.core -ErrorAction SilentlyContinue
# srcInput can be either vCenter or CSV
$srcInput = "vCenter"
$csvFile = "C:\Scripts\myserverlist.csv"
$vCenter = "vcenter.domain.com"
# Creates a list of PuTTY sessions currently on the system
$puttySessions = @(Get-ChildItem -Path registry::"HKCU\Software\SimonTatham\PuTTY\Sessions\")
$i = 0
# Shows a list of PuTTY sessions, for choosing a base session when importing servers
Foreach ($puttySession in $puttySessions) {
$puttySessionName = $puttySession.ToString()
$puttySessionName = $puttySessionName.Split("\")
Write-Host "[" -nonewline; Write-Host $i -ForegroundColor Yellow -nonewline; Write-Host "]" $puttySessionName[-1]
$i++
}
Write-Host `n
$puttySessionChooser = Read-Host "Choose from the list above, a PuTTY session you would like to serve as basis for the imported sessions"
$puttySessionChosen = $puttySessions[$puttySessionChooser]
if ($srcInput -eq "CSV") {
# Import list of servers to be created as PuTTY sessions
$servers = @(Import-Csv $csvFile)
}
else {
Connect-VIServer -Server $vCenter
$servers = Get-VMHost | where {$_.State -eq "Connected"}
}
$l = $servers.Length
$i = 0
$puttyTemplate = Get-Item -Path registry::$puttySessionChosen
#$puttyTemplate
#break
# loops thrue all the servers and creates corresponding keys in the registry
Foreach ($server in $servers) {
$srvName = $server.Name
New-Item -ItemType "Directory" HKCU:Software\SimonTatham\PuTTY\Sessions\$srvName | Out-Null
New-ItemProperty HKCU:\Software\SimonTatham\PuTTY\Sessions\$srvName -Name "HostName" -Value $srvName -PropertyType String | Out-Null
# loops thrue all the values from the chosen PuTTY session in the first part of the script
Foreach ($registryValueName in $puttyTemplate.Property -ne "Hostname") {
$registryValueLookupString = $(if ($registryValueName -eq '(default)') {$null} else {$registryValueName})
$regName = $registryValueLookupString
$regType = $puttyTemplate.GetValueKind($registryValueLookupString)
$regValue = $puttyTemplate.GetValue($registryValueLookupString)
New-ItemProperty HKCU:\Software\SimonTatham\PuTTY\Sessions\$srvName -Name $regName -Value $regValue -PropertyType $regType | Out-Null
}
# since all output from the above commands are "null" the following progress bar shows the script execution status
$progress = [math]::round(100*$i/$l, 0)
Write-Progress -Activity "Creating PuTTY sessions..." -PercentComplete $progress -CurrentOperation "$progress% complete" -Status "Creating server: $i of $l"
$i++
}
Keep your IP settings when changing NIC in a VM
Sometimes you need to change or upgrade the network card in your VM for one reason or another. Maybe efter a P2V the IP address of the physical server was not migrated, or you are upgrading from VMXNET2 to VMXNET3 or some other NIC type.
Using netsh in Windows you can dump your NIC information (IP, subnet, DNS and so forth) to a txt file, and when you have changed the NIC in your VM, easily restore the configuration to the new NIC.
The script below is nothing but a simple batch script that wraps NETSH commands for either restore (netsh exec) og backup (netsh dump) commands. Copy the below script to the desktop of the machine you are about to change NIC in
Netsh dumps information based on the name of your connection, which typically is "Local Area Connection". This means that when you have changed your NIC and the VM boots backup with a new NIC, you would have to rename that new connection, so that it matches the name it had when you ran the RESTORE command.
Note that DNS suffix, WINS and routing tables are not part of a netsh dump command.
This quick guide below outlines the steps for using the above process. You could do this without using the script, it just makes things somehow easier. (and i cant stop myself from doing small scripts once in a while...)
- Copy the below script to the machine where you want to backup the NIC information.
- Run the script and enter BACKUP when it prompts. This will create a ipconfig.NETSH file containing your current IP settings.
- Go to network settings, and note the name of your current adapter. Typically "Local Area Connection"
- Shutdown the machine and make whatever NIC changes you have planned.
- Power the machine back on and issue the following command from a CMD prompt:
set devmgr_show_nonpresent_devices=1 - Start Device Manager afterwards using the following command:
devmgmt.msc - Go to View and check "Show hidden devices"
- Expand "Network adapters" and delete the old adapter from the system.
- Go to network settings and rename your new connection to match the name you noted in step 3. Netsh restores based on what name your network connection has.
- Run the script from step 2 and this time enter RESTORE. This will restore the settings in the ipconfig.NETSH to your new adapter.
And here is the script. Just save as a .bat file.
@ECHO OFF :LOOP SET /P USERPARM=Please enter BACKUP for backup or RESTORE for restore: IF "%USERPARM%"=="" ( ECHO Nothing is entered GoTo :LOOP ) IF /I "%USERPARM%"=="backup" ( NETSH interface ip dump > ipconfig.NETSH ) ELSE ( IF /I "%USERPARM%"=="restore" ( NETSH exec ipconfig.NETSH ) ELSE ( ECHO The param entered is not RESTORE nor BACKUP ) )