Jeroen and I are pleased to announce the release of the long awaited 'Phase V' whitepaper which gives unbiased and independent insights in the impact and best practices of various antivirus solutions on VDI. We truly believe we have interesting new content and many new insights which is needed for every successful VDI project. The desktop virtualization industry is maturing: we learned about storage, we learned how to tune the Windows desktop and hypervisor for performance and know how to create scalable VDI solutions. Interestingly, once everything is up and running, in many VDI deployments one piece of the performance pie is still overlooked: the antivirus solution.
Too many times, moving into production, performance is not as expected. Often in these cases, antivirus solutions prove to have a considerable impact. Technologies like heuristics scanning add considerable weight to the scanning process. Normally, with regular desktops or laptops, this is not a problem. There’s plenty of CPU and disk I/O capacity available exclusively to the (PC of the) user. However with hosted desktops this is different. A performance impact of up to 40 percent is not unusual after AV is installed. While this has been less of an issue with PC’s or laptops, with VDI it means you need to invest in 40% additional server capacity, or even higher when you look at the impact on storage.
For this reason Project VRC decided to investigate the impact of antivirus solutions on VDI. The following questions were asked:
- What is the performance/capacity impact of the most well-known AV solutions when used in a VDI environment?
- How do AV solutions designed for virtual environments with so called “off-loading” architectures compare with conventional solutions from a performance perspective?
- How does the disk IO impact compare with the different AV solutions, conventional and off-loading architectures?
- What is the performance impact in stateless desktop environments in comparison to stateful desktops?
- What possibilities are there for performance tuning and how does this affect the overall impact on performance impact?
The purpose of the whitepaper is to find answers to these questions!
ProjectVRC focuses on the most common ones: Microsoft System Center Endpoint Protection (ForeFront), McAfee Enterprise, Move Multiplatform, Move Agentless and Symantec Endpoint protection. Testing AV solutions proved to be more complex and more unpredictable than originally expected. It became very clear that most AV solutions were designed for typical Desktop and Laptop environments, not for (stateless) hosted virtual desktop environments. There is an important lesson to be learned here: the impact of antivirus is considerable, and it’s vitally important to review and test this before rolling out an AV solution in a VDI environment. This is confirmed in the large majority of real-world VDI deployments, time and again.
This whitepaper contains more data from more different configurations than any previous ProjectVRC publication. The findings are sometimes a little surprising. A key outcome of this whitepaper is the best practice to perform a pre-scan of the master image before it’s deployed. The effect is dramatic and therefore highly recommended. Many different performance optimizations were tested. However, many are also difficult to recommend because they lower the amount of security features and would result in objections from security officers. Luckily, performing a pre-scan of the master image would not cause objections.
Another key finding is that off-loading architectures make a big difference from a storage IO point of view, but not always from a session density point of view. In comparison to conventional AV solutions, off-loading AV architectures have clear advantages (such as minimizing scanning overhead, central updates and minimized footprint per desktop VM). Nonetheless, off-loading architectures still needs to mature: technically they can be complex. Off-loading architectures create a very high dependency of the desktop VM’s to the performance of the off-loading VM itself, especially when the server host is close to saturation. Also, off-loading architectures sometimes introduces higher application start latency, because the actual scanning of files is performed on a different VM. Overall, the capacity impact on session density of using AV solutions within VDI with default settings ranges from 5 to almost 40%. Such impact has been witnessed, even with scheduled updates and scans disabled, and full pre-scan performed of the master image. Still, in the real world the performance impact of AV solutions can be easily bigger.
When comparing various AV solutions, the conventional Microsoft System Center EndPoint Protection (SCEP) previously known as Forefront, seems to have the least performance impact, but only after performing a full pre-scan of the master image before deployment of the desktop VM’s. This is a huge difference to ForeFront tests done without pre-scan of the master image (in those tests, without pre-scan, the performance impact was dramatically high).
It is important to highlight the fact that Project VRC does not evaluate quality of the security features in any way.
While one AV solution might have a lower performance impact, it could easily also mean that this AV solution is less effective to its competitors. It is important to include this into your own discussion about AV within VDI. We also realize that in many VDI environment there is no choice and configuration freedom, because of security policies and / or decisions made outside the VDI team. It’s therefore critically important to educate colleagues about the impact of AV on VDI - hopefully this whitepaper can help with that process!
As usual, you may download the paper from www.virtualrealitycheck.net.
Also, you can follow us on twitter: @RSpruijt (Ruben Spruijt), @TheJeroen (Jeroen van de Kamp) and @ProjectVRC.
Do you have feedback, ideas or suggestions to make ProjectVRC better? email@example.com
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.