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.
