![]()
Updated post 31/01/2013
Earlier this week Condusiv hosted a webinar specifically focusing upon V-locity. It was a scheduled 30 minute slot but due to so many questions, good ones too, it ran over slightly. So, if you’d like to learn more about how V-locity works, it’s intelligence and optimisation techniques, I’d recommend watching this video of the webinar.
Updated post 11/01/2013
I’ve updated this post after discovering my lab environment wasn’t providing a consistent platform for the tests to be completed upon.
My sincere apologies to Condusiv for poorly reporting on their product however; I’ve undertaken the testing again and received dramatically better results. Please see the tables below, you’ll observe a vast difference now. For clarity and tracking I’ve crossed through the old results but left them visible as there was a marked difference even in my IO constrained environment.
Since looking into this product I’ve also had the opportunity to run the Benefits Analyzer Tool too, the output of which can be seen towards the end of this article. Excellent results reported on my vCenter even for a low utilisation home lab environment, I suspect there’s much potential to be observed in the real world based on these findings.
Summary
While attending the UK VMUG recently in November I took time to wander around the mini-solutions exchange and chat with some of the vendors to see how the market was doing for them, dig a little further and learn about new technology. Of the many offerings available, one product from Condusiv grabbed my attention – specifically V-locity4. It claims to boost virtual machine performance up to 50%, without the need for extra hardware by optimising data reads and writes using the virtual machine’s own RAM. With so many virtual infrastructure complementary solutions in the marketplace, it’s hard to invest time for every single one but something about the description and its deep seated roots from the old VAX days led me to think it was worth further investigation.
[Disclaimer] I’d like to clarify to you, the reader, that I’m not affiliated with Condusiv, have not been sponsored, paid or beaten into submission to produce this article. Images and statistics that I’ve included in this article that are not my own have been provided to me from Condusiv for the purpose of clarity and respect for accuracy.
The test ‘lab’
To set the scene for the testing it’s important to explain my mini-lab. It’s nothing along the lines of Michael Webster’s or Mike Laverick’s so please don’t be too disappointed
. If you’re familiar with my blog site you’ll notice that I have Sean Duffy’s vMetrics updating once an hour so it’ll affirm my kit list here.
Hardware
- 2 x HP ProLiant N40L Microservers each with 8GB RAM and local disks
- 1 x HP ProLiant ML115G5 with 8GB RAM and local disks
- 1 x Iomega IX-200 with 2 x 1TB drives in RAID 0
- Cisco unmanaged desktop switch, 8 Port, 1GbE
Software
- VMware ESXi v5.0 Build 821926
- VMware vCenter v5.0 Build 804277
Configuration
- VMware ESXi installed locally in each server, not USB or AutoDeploy
- IP Network using 192.168.15.0 / 24
- Static IP for hosts and storage
- Virtual machines use a mixture of static and DHCP
- DHCP provided by Cisco Linksys EA4500 router
- Single iSCSI presentation of 1TB from Iomega
- Single Datacenter and single HA & DRS (most aggressive setting) Cluster
I think that’s enough to be getting on with, now onto the building of the V-locity 4 setup.
V-locity test machines
Virtual hardware
I created 2 x MS Windows 7 (64-bit) virtual machines, each machine created with identical virtual hardware:
- 1 x vCPU with a single core
- 3GB RAM
- Video card with 8MB RAM
- LSI Logic SAS SCSI Controller
- 1 x 32GB Hard disk, Thick Provisioned Lazy Zeroed
- 1 x CD/DVD, disconnected when not in use
- 1 x vNIC (E1000)
Guest operating system and personalisation
- MS Windows 7 Professional with Service Pack 1 (ISO build 623707) installed, automatic updates turned off
- Performance Profile, Maximum
- Screen saver turned off, screen sleep and computer sleep disabled
- No other software installed (anti-virus, Adobe, etc…)
- Virtual machine names:
- vlocity-01
- vlocity-02
- IP configuration left at default of DHCP
- VMware Tools installed into both virtual machines, build 821615
- DRS Rule created to keep both machines together (thinking about the benefits of shared memory etc…)

IO Generating software

For this test, IO Meter software was downloaded from here and installed into both virtual machines. I chose the default options and when the installer completed I answered, “The program installed correctly”, when prompted by MS Windows. When I launched IO Meter I granted the program “Allow Access” for both prompted messages.
V-locity, installation
For the purpose of this review, the test required that the software is installed into one virtual machine, this way you’re able to see a virtual machine running with it and without it. In this scenario my virtual machines are:
- vlocity4-01 – IO Meter installed without V-locity 4
- vlocity4-02 – IO Meter installed with V-locity 4
I download the 30-day trial from the Condusiv website and launched the installer.
[Yak Shaving Tip] If your test lab doesn’t have internet access make sure you have a copy of the ‘Microsoft .NET Framework 4.0 Client’ software to hand and install this into the virtual machine where V-locity 4 will reside. The installer will check and retrieve it (if required) from the internet during the deployment but if your lab doesn’t have internet access you won’t get very far.
I chose the Advanced installation as I’m not a huge fan of the Express installs, you never quite know what you’ll get. Anyway, I’ve included the main screenshots below so you can see their options.







Configuration, both virtual machines
The virtual machines were configured to complete the same tasks, in this test I opted for 2 types of interrogation.
- 100% read
- 50% read and 50% write
I ran the tests with the sequential setting and then random setting to compare the results and see where the benefits exposed themselves within my environment.
When each test was executed on the vlocity-02 virtual machine a run time of 3 minutes was completed followed by a wait time of 2 minutes prior to the actual logged and reported upon figures. This allows the V-locity system time to track the workload and balance it’s algorithms accordingly.
As this software is very Read cache focused the benefits of Write performance will only reveal themselves during low fragment write requests. In my testing scenario here I used a 4kb block size and 4kb write so in reality I didn’t expect to gain too much from this.
IO Meter configuration specifics
To summarise the IO Meter Worker profiles:
- Each virtual machine was allocated 2 workers
- A maximum disk size value of 50,000 sectors using the local ‘C’ drive of the virtual machine
- Each worker was assigned the same task from the Global Access Specifications
- I set the Results Display to Last Update and every 2 seconds
- Reporting was saved to a CSV file
V-locity performance results
All tests ran for a minimum of 10 minutes to allow the guest OS within each virtual machine to stabilise and the host hypervisor to balance out the compute workload.
Sequential access
(Unstable test environment entries crossed through)
100% read test improved IOps by 45%50% read and 50% write improved IOps by 52%
(Tests undertaken in a more stable environment)
The table below clearly shows that with V-locity 4 running within the virtual machine the:
- 100% read test improved IOps by 899.87%
- 50% read and 50% write improved IOps by 307.51%

You’ll notice that the CPU utilisation is higher in the vlocity-02 virtual machine, this is because the agent is using the idle CPU cycles to process in-flight requests, these are relinquished when the guest operating system needs them. To cover the host perspective, vCenter performance reports showed no Balloon or swap activity so this didn’t appear to adversely effect my alerting or reporting.
Had I pushed out smaller 1kb or 2kb writes then V-locity would have applied its caching and intelligence to only lay down an actual write once the block was size was complete, so the poorer performance more than likely reflects the underlying storage rather than the product.
Random access
(Unstable test environment entries crossed through)
100% read test performed worse to the tune of -8.75%50% read and 50% write improved IOps by 48%
(Tests undertaken in a more stable environment)
The table below clearly shows that with V-locity 4 running within the virtual machine the:
- 100% read test improved IOps by 408.76%
- 50% read and 50% write improved IOps by 38.21%

As I mentioned in the Sequential access section above the CPU is noticeably higher for the Read tests, whereas Writes required a lesser amount of CPU processing. The random access test in my environment using a 4kb Write on a 4kb block size reveals my storage can’t quite keep up with the intensity of random requests.
Summarising all of this
I’ve certainly established there are marked differences and wins to be had using this software in my own lab environment. Yes, you can clearly see the software is designed for the acceleration of disk Reads but it can also address Writes as I’ve elaborated upon above. From my perspective though I’m glad I’ve seen a little degradation in my environment as I now know where my bottlenecks would be and it’s proof where V-locity wouldn’t be of value in my setup. No two environments are the same even with identical major core applications so until you’ve actually had a look and tested it for yourself I wouldn’t rule this product out. I have to admit that I’ve not spent any time looking into the rest of the product and it’s features – I was drawn in by the technology and not the add-ins. One item of interest for those of you looking to kick the tyres more is the “3 Day Benefit Analysis” report, this watches the virtual machine activity to help shape its ‘working’ profile. A report can be generated after this capture to assist with any business case or justifications that you may need – a utility that’s also a reporting tool, nice.
Here’s my report (in full) having run the Benefit Analysis tool against my vCenter server, as you can see there’s benefits to be had by using V-locity. A quick snippet below…

The Condusiv website covers off many more of the V-locity 4 features and how it can help to address IO bottlenecks and redundant IOs, so I won’t list them here. For peace of mind the product has been tested by VMware and awarded the VMware Ready logo, you can read more here about this.

So, wrapping up this mini-investigation I hope you too are now intrigued to see how it’ll perform in your lab. I’d been keen to hear your findings and also if you’ve it deployed into your development, test or production environments.


6 GHz Total CPU
16 GB Total RAM
2,852 GB Total Disk
2 Host(s)
1 RPs
8 VMs
330 vMotions
(6)
(2)
(0)
46 Physical NICs
12 Virtual PGs
Office
I am curious, what was wrong with your initial environment configuration that let you to scrap the results and start over?
Hi Jeffrey.
It wasn’t so much the configuration per-say but more about my NAS device being intensely busy during the testing period, I naturally assumed it was due to stress test loads as I was trying all manner of things, at the time I didn’t really pay too much attention to it. Prior to undertaking the testing I freed up some shared datastore space by Storage vMotioning a couple of VMs to a local drive on one of the hosts but I did wait until that completed before deploying the new test VMs.
The following day when I went back to my home lab the NAS box disk activity was still beating itself senseless, something I realised wasn’t right, I hadn’t even switched on my monitor so I knew it wasn’t me. Having checked my VMs nothing out of the ordinary seemed to be happening, but I chose to power them down to be completely sure. With no VMs active, only the hosts connected to the iSCSI paths the NAS disk access LED wouldn’t calm down. I logged into the Iomega console, which was a little sluggish, and requested a shutdown. This took over an hour to process but eventually gracefully powered off. Since then it’s been fine, I’ve double checked the firmware is the latest, I can only assume the management interface took a nose dive.
Hi Dawoo,
considering Windows 7 file system has 512 Bytes per sectors, in your benchmark IOmeter was configured to stress a portion of 25000 KBytes of storage which is fewer than IntelliMemory cache. In this case all disk I/O are optimized in RAM.
Did you try to test the storage optimization on large file system (more than memory cache) like 10-20 GB ?
Hi Luca, thanks for the question and if I’m understanding it correctly you’d like a test to be run for a Random Read of size 10GB?
I’ve opened up the IO Meter software and the largest transfer request size is 1GB, would you like to me run a set of tests using this? If so, what block size would you like? 512b, 4K, 16K or 32K?
Darren.