In this post we will run through how to record or capture the amount of IOPS being generated by one of your systems. The method we will be using is the Windows Performance Monitor (perfmon). I used this method for recording the IOPS from desktops computers at my workplace when sizing for a VDI project, so lets get started.
Step 1. Click right on Computer and select Management. Under Performance > Data Collector Sets > User Defined. Click right on the User Defined folder and select New Data Collector Set.
Step 2. Set a name for your performance counter and select Create Manual Advanced and click next.
Step 3. Click Create Data Log and check Performance Counter then click next.
Step 4. Set the time interval to 10 seconds and click Add.
Step 5. Locate Local Disk from the left hand menu and add the options (Disk Reads/sec, Disk Writes/sec, Disk Transfers/sec) and click OK.
Step 6. Double click on the item made under the User Defined folder and right click on the Data Collector and select Properties.
Step 7. Under log format, select Comma Separated and click OK.
Step 8. Select the performance counter and click the play button to start collecting data.
Step 9. Once you have collected your data for a period of time, navigate to the following location C:\PerfLogs\Admin\yourcountername. Now load the Excel document to display your collected IOPS. Within the excel document you can calculate figures such as the average IOPS, maximum IOPS, as well as putting together a graph that illustrates the activity of the IOPS by specifying the Read and Write columns.
Thanks for reading and lookout for my other articles on storage and IOPS calculations.
There are a number of options and settings that can be tweaked withing Windows 7 to increase its performance and reduce its storage I/O. This is particularly useful when planning on using Windows 7 in a VDI environment as it can decrease the overhead and storage impact of multiple VMware View session.
VMware have released a recommended configuration guide to optimise Windows 7 for VDI as have many other bloggers. To combined this collected set of recommended Windows 7 tweaks, I have published both a script and registry files that can be used on a base Windows 7 virtual machine before you begin to either deploy, or clone for use with VDI.
The script and registry files are to be used together to invoke the necessary changes. Once applied, the changes will be reflected on all post user profiles created. Follow the below steps on how best to apply these optimisation settings.
Step 1. Create a new Windows 7 virtual machine and login as a local administrator.
Step 2. Run the following registry files that can be found here. Reg1 | Reg2
Step 3. Run the following batch script that can be found here. Script
Step 4. Continue by cloning this virtual machine or test its effects by logging in as a general users.
By using these optimisation teaks, I found the I/O impact on my VDI environment had reduced as well as an increase in refresh rate during a View session for users at remote locations.
Thanks for reading and be sure to check out my other posts on VDI and Windows optimisation.
When connected to a VMware View session you may have noticed that you do not have access to change any display settings. This can be a problem for users that have a large monitors as View auto sets the desktop resolution for best clarity. In my experience, I have had users complain about how small icons and text are shown within their View session which at the time I didn’t have a solution for.
Thankfully, VMware have bundled a group of ADM templates containing many options for tweaking View components such as the View agent and PCOIP parameters. You can fine these ADM templates on any one of your connection servers in the following location.
In this post we’ll go over writing a View PowerCLI script to schedule a recompose of a desktop pool.
If your like most VMware View administrators you’ll probably use linked clones, and know that now and again these clones will need recomposing to keep up to date with operating system patches or updates for embedded applications. If your organisation is like mine and operates on a 24 hours basis, getting downtime to perform a recompose can end up being headache and is usually scheduled for a unsavory hour.
Unfortunately scheduled tasks was not part of the View v5 release which i imagine left many people in my situation slightly disappointed. To get around this need for functionality, i turned to the View PowerCLI extensions and wrote a script to perform my desired tasks.
Below you will fine my script, along with one of my working examples that allows you to specify a linked clone pool to be recomposed from a specific virtual machine and snapshot at a defined time and date.
In this post I will detail how I calculate the impact of storage IOPS on your SAN based on the number of front end IOPS and chosen RAID configuration. There are two terms around IOPS you may hear people referred to as front end IOPS and back end IOPS. This post will detail what’s these two terms mean and how’s these relate to the impact on you SAN.
Front end IOPS are the number of input output operation per seconds coming from your servers or desktops (if your using VDI). This is number of reads or writes that come into your SAN from either your Ethernet or fibre switches.
Once these IOPS hit the SAN, depending on weather they are read or write requests, the SAN then has to perform the relevant request based on the RAID configuration set on the SAN. For example, if I make a write request to my SAN from a server which generates 10 IOPS, if the disk group on the SAN is in a RAID 1 it will write the data twice, therefore doubling the (back end) IOPS on the SAN. 10 IOPS comes in, 20 IOPS are the impact.
This increase in IOPS on the SAN is due to the RAID penalty of the RAID configuration chosen. The RAID penalty for each RAID configuration is detailed below.
“So, when calculating the impact of the penalty on the SAN, you simply multiply the front end IOPS by the RAID penalty, right?”
No, the RAID penalty alone isn’t the full picture but would give you the worst case scenario. You need to now take into account the read write ratio. The read write ratio is usually different for everyone, and because of this it is hard to estimate what your read write is going to be unless you have a working example in place i.e. a proof of concept. If you’re planning on sizing for a particular application or service it can be easier to estimate. For example, databases are mostly write intensive, and web servers are mostly read intensive.
If in doubt, a common perception I have seen from many articles is a ratio of 20% read / 80% write. This is usually a good basis to work from as writes are much more intensive on the SAN, however to ensure you don’t over size too much, having 20% read is often a safe bet for good a mixture.
So now we know what causes the IO impact on a SAN, let’s run through an example.
After monitoring my environment, I have calculated an average of 1500 front end IOPS.
I plan to configure my SAN in a RAID 5 configuration (penalty of 4).
I will be working on the basis that my read write ratio is 20% read / 80% write.
Step 1. Subtract the read percentage from the RAID penalty (4 – 20%) = 3.2
Step 2. Multiply the new RAID penalty (3.2) by the number of front end IOPS. 1500 x 3.2
Step 3. Take 20% of your front end IOPS for the total read IOPS (20% of 1500 = 300)
The total impact on the SAN for this example would be 5100 IOPS (300 Read / 4800 write)
Bear in mind this calculation is not 100% accurate but will give you a rough estimate on the amount of IO you will require on your SAN based on your chosen RAID configuration. This exercise is a good way to size up you requirements when considering what SAN to buy.
This is the method I used when sizing for a VDI environment. The SAN I was looking at buying was only configurable in a RAID 6 therefore I knew what penalty I was looking at and ultimately how many IOPS my environment would impact on the SAN based the on back end IOPS.
Thanks for reading and lookout for my future posts on storage performance and sizing.
In this post I will detail how to make use of the VMware View PowerCLI extensions. One feature I has hoping to see in the release of VMware View 5 was the ability to schedule tasks such as refreshing desktops or recomposing entire pools. Unfortunately this feature wasn’t added to View so i seeked my own solution. With View PowerCLI you can perform most if not all main functionality and better still, schedule when you went these commands to run. In this post the relevant commands for scheduling the refresh of a pool at a defined time are outlined.
VMware PowerCLI can be a very powerful tool in managing your vSphere environment. To get started there are two installs you will need to download and execute on to either a server or workstation that has visibility of your vSphere environment. Once installed you’ll be able to experiment with scripting commands and scheduling tasks. Remember to look out for a later post on using PowerCLI scripts with VMware Site Recovery Manager.
With application virtualisation legacy applications can be made available on newer operating system platforms, in particular 64 bit architectures. VMware ThinApp is designed to allow 32 bit application run on 64 bit operating system natively out of the box, however with some applications this doesn’t always work as expected.
Within the ThinApp packager there is an option you can enable that allows the emulation of a 32 bit platform for your virtualised application allowing its use on a 64 bit operating system. The following steps detail how to enable this feature.
Step 1. Before building your application, edit your package.ini file by uncommenting the wow64=0 entry as shown below.
Step 2. Save your package.ini file and built your application.