Stress Testing CPU Loads on vSphere with StressLinux

In many of my articles I highlight the use of the VMware I/O Analyzer tool, a small OVA appliance that can be downloaded from the VMware Fling labs area. This is great for doing some heavy benching of various storage workloads of unique sizes and directions. However, sometimes I look to another tool for doing some general purpose stress testing: StressLinux (Download Page). As stated by the developers:

stresslinux is a minimal linux distribution running from a bootable cdrom, usb, vmware or via PXE (wip).

stresslinux makes use of some utitlities available on the net like: stress, cpuburn, hddtemp, lm_sensors …

stresslinux is dedicated to users who want to test their system(s) entirely on high load and monitoring the health.

Now that you are aware of what it is and what it does, let’s look at how to use it.

Acquiring StressLinux

Fortunately for you, the application is available in a pre-assembled VMX file that you can import using the VMware vCenter Converter Standalone Client. Even if you already have this tool, make sure you are running the latest version (5.0.1 build 875114) as otherwise you may encounter some application crashing when connecting to a vCenter 5.1.0 server (or at least, I did until I upgraded). Snag the latest stresslinux file that is listed for “VMware Appliance” with a component type of “vmware”. Then, extract that container to find a single VMX and VMDK file. Load these up in Converter and convert it into your vSphere environment.


Before you power on the VM, you may want to tweak the number of vCPUs to match a more worthy workload than one. I set mine to 3 vCPUs.

spongebob-stressedStress Testing the CPU

While the StressLinux VM can do a lot of different tests, I’ll demonstrate the CPU one. First, make sure to log on as “stress” with a password of “stress”. Then, answer the series of questions (I usually end up hitting enter to all the defaults). Once that’s done, you’re ready to test.

Use the command

stress --cpu X

Where “X” is equal to the number of CPUs to test.


You should notice that ESXTOP shows a heafty amount of load going on for that VM. You can load up several of these appliances to test for %CSTP, %RDY, or even NUMA issues. In my case, I am simply running this one VM on a test host to demonstrate.



This is a really handy, small sized tool for generating CPU load. In the past, I have relied on a few other methods (such as Prime95) that require a bit of configuration leg work.

If you want to explore more with this tool, you can see that it contains a great number of arguments that can be passed to stress.


You can also run the x86info command to get an idea of what the VM is seeing from a hardware perspective.