VMware or Microsoft: Protecting VM’s – Agents or Agentless?

“When it comes to protecting VM’s, treat your virtual machines exactly like you do your physical machines”

This is a message I was communicating to IT Pros 10 years ago when we first released Microsoft Virtual PC. At the time, virtualization was a new concept to many IT departments. Security and backup/recoverability are always a top concern and one of the questions around virtualization was how to protect VM’s from virus and malware attacks as well as be able to recover them in the event of a catastrophic failure. My answer above was usually to these questions -

“Do I need to run anti-virus and anti-malware software of virtual machines"?

“If I backup the entire server, do I still need to back up the VM’s?”"

Fair questions considering the very low adoption of virtualization technologies at the time. Many IT Professionals wondered if it was even necessary to install anti-malware software to a virtual machine if it was installed and maintained on the “host”.

“Does installing an anti-virus application on the host, protect the virtual machines?”

This was also a common question at the time. Thus, my answer of treating a virtual machine exactly like a physical host. Virtual machines need to have Windows Update security patches applied to them just like physical hosts. Why wouldn’t they need to have anti-virus protection as well?

“But doesn’t installing anti-virus on the host protect the VM’s? The VM files are on the host and the anti-virus scans those files”

True. The VM files are on the host, but just like Exchange and SQL databases, when a VM is running, there are file locks in place that may allow scanning, but don’t allow modifications to be made. In addition, one or more of those files represents an entire operating system and all of the applications that run on top of the operating system. So we have file locks within file locks. Anti-virus applications at the time weren’t written with the ability to unwrap those layers to peer into the VM’s. Wrapping our heads around these logical boundaries took some education and time to figure out.

“I did a full server backup including the VM repositories, I am covered, right?”

I guess technically you are, but what if there is an individual VM failure and I need to recover just one directory that was on a VM? Or just one file? If we have to restore an entire VM from a full server backup, that could take a significant amount of time depending on the size of the VM. Then we still have to extract the directory or file in question. What if the host fails? Then I have to extract each VM from the full server backup and restore to another host or to a rebuilt server.

Fast forward 10 years and the landscape has changed dramatically. You will be hard pressed to find any IT shop that isn’t virtualizing some if not most of their workloads. IT staff know how layered virtualization is and they know that protecting virtualized workloads is just as important if not more so than it ever was. A more likely scenario is that VM workloads are clustered. They have become much more portable than they were 10 years ago. This actually increases the need for more granular backups on individuals virtual machines.

When it comes to protecting the workloads enterprises run on their hypervisors, there has been some debate about whether the best approach is to use a system that require an agent or those that are agentless. As with all solutions, there are trade-offs with either approach. The purpose of this article is not so much to come to a conclusion as to what is better, but to set the record straight on how VMware positions their solutions vs what Microsoft has to offer.

Let’s look at some of the claims…

VMware claims they use an agentless strategy to protect client VM’s running on VMware hosts. - In reality, each VM requires the installation of the VMware EPSEC Driver (endpoint security) for virtualization security. This is a thin agent that is responsible for transferring files and information to a Storage Virtual Appliance (SVA) where anti-virus scanning takes place. The CPU cycles simply get moved to another location. Each virtual machine also still requires the installation of the VMware tools to support the vShield technologies as well as vSphere Data Protection. If it were truly agentless there would be absolutely nothing to install to the endpoints.

VMware claims this agentless approach “eliminates the agent footprint from virtual machines” – The end result is that we should be able to save CPU cycles and increase VM density on a per-host basis. While it is true that individual VM’s will not be processing scans, and thus reduce CPU cycles, the trade off is the potentially increase in network traffic by transferring data to an SVA (which also needs to be managed).

The graphic above says “Built-in vShield Endpoint” when in fact there is a considerable amount of configuration and overhead to make it work. A 4-node ESX cluster requires 6 virtual appliances – 2 for management (1 for the vShield Manager and 1 provided by a 3rd party antivirus vendor) and the 1 for each node of the cluster. That is a lot of extra overhead and it can easily be questioned whether the resources required to run the appliances is less than the resources used when running agents on the individual guest VM’s. This is especially true in a configurations in lower densities.

Also, deploying anti-virus on endpoints is not enough to protect them. The threats we encounter today go well beyond just anti-virus protection to include, real time browser based attacks, reputation based systems for assigning ratings to applications and web sites, behavioral application scanning, social engineering attacks and more. All of these are client side functions and can’t be offloaded. In other words, you will still require separate policies and/or separate mitigation capabilities through additional hardware or software solutions. The mere installation of the VMware EPSEC driver and use of vShield does not “eliminate” the footprint at all. It merely shifts a portion of the footprint elsewhere leaving administrators to still manage the remaining attack vectors on the endpoints as well as manage the new SVA overhead and the resulting network traffic. We may even need to install other 3rd party agents to mitigate these vectors. These agents or software may nullify CPU gains and of course lead to additional management. Ultimately, we may not save any CPU cycles at all or be able to run at higher densities at all.

Legacy Physical Security – I am not sure what this even means in the context of Agentless VM Protection. I went searching for an explanation and the closest I came was in a VMware vCloud Networking and Security Whitepaper discussing software defined networking. But that is vCloud, not vShield. Not built in, and not free. When it comes to virtualization, we have a physical hosts which require the obvious physical security protections. Beyond that I am going to do some additional research to try to find out what this means.

vSphere Agentless Backups / System Center DPM Requires Agents on all VM’s - System Center DPM requires an agent only on the Hyper-V host not all of the VM’s. Once installed to the Hyper-V host, the VM’s hosted on the Hyper-V server can then all be backed up via VSS. If we need to do item level recovery on VM’s, then yes, we do need to install the DPM Agent to each VM.

VMware Data Protection requires an agent to back up SQL and Exchange – I have been to many local VMware meetings, VMUG’s and VTUG’s over the past 3 years. One of the recurring themes I hear is how SQL, Exchange and SharePoint are the most commonly virtualized workloads on VMware platforms. SQL and Exchange require an agent to be backed up by VDP (and SharePoint SQL repositories as well). This also requires an upgrade to vSphere Data Protection Advanced because the “standard” edition doesn’t have the agent.

VMware actual explains “What are the benefits of using a SQL Server/Exchange agent?” in their  See the following -

Here is some additional information on Microsoft System Center 2012 Endpoint Protection (SCEP) and System Center 2012 Data Protection Manager (SCDPM)

System Center 2012 Endpoint Protection (formerly Microsoft Forefront Endpoint Protection) - Combines management and security into a single solution. Most desktop vulnerabilities are a result of poor system configuration, yet security administrators lack ready access to inventory, patch level, and other desktop-specific data. System Center 2012 Endpoint Protection gives organizations industry-leading threat detection capabilities built on Configuration Manager 2012. Because of this integration *and* because we are using an agent, we get the benefit of being able to mitigate the items mentioned above - real time browser based attacks, reputation based systems for assigning ratings to applications and web sites, application behavior scanning, social engineering attacks – using centralized security and application control policies.

We also use a single Configuration Manager Agent for managing client configuration and security. This limits the amount of agent management required on client machines. We also provide agents that allow us to support a broad variety of Mac and Linux based clients right in the box with no reliance on 3rd party vendors.

System Center 2012 Data Protection Manager – By default, SCDPM can provide online backup of running VM’s leveraging the Hyper-V VSS writer to ensure that consistent versions of virtual machines are captured and protected without affecting machine access. The ability to back up open files is critical for business continuity, and Volume Shadow Copy Services (VSS) is a technology that creates frozen copies of open files. It ensures that virtual machines do not have to be put into hibernation or be shut down before a consistent backup can be made. VSS, DPM, and Hyper-V interact as follows -

• The DPM block-based synchronization engine makes an initial copy of the protected virtual machine and ensures that the copy of the virtual machine is complete and consistent.
• After the initial copy is made and verified, DPM captures backups by using the Hyper-V VSS writer. The VSS writer provides a data-consistent set of disk blocks that are synchronized with the DPM server. This approach provides the benefit of a "full backup" with the DPM server while it minimizes the amount of backup data that have to be transferred across the network.
• The DPM protection agent on a server that is running Hyper-V uses the existing Hyper-V APIs to determine whether a protected virtual machine also supports VSS.
  • If a virtual machine is running guest operating systems beginning with Windows Server 2003, and has the Hyper-V integration services component installed, then the Hyper-V VSS writer recursively forwards the VSS request through to all VSS-aware processes on the virtual machine. This operation occurs without the DPM protection agent being installed on the virtual machine. This recursive VSS request allows the Hyper-V VSS writer to ensure that disk write operations are synchronized so that a VSS snapshot is captured without the loss of data.
  • The Hyper-V integration services component invokes the Hyper-V VSS writer in Volume Shadow Copy Services (VSS) on virtual machines to ensure that their application data is in a consistent state.
  • If the virtual machine does not support VSS, then DPM automatically uses the Hyper-V APIs to pause the virtual machine before they capture data files.

I hope this information lends some perspective to what VMware and Microsoft products can and can’t do. As always, I enjoy your feedback and I am happy to answer your questions!

-Cheers