VM-Centric Operations for VMware VSA

VM-Centric Operations Overview

The Virtual Server Agent (VSA) for VMware^® has achieved a major redesign in service pack 14. As a result, the VSA agent has soared to new industry heights for protecting VMs. Operations now focus on individual VMs rather than VSA subclient levels, which offers the granularity necessary to perform your daily tasks. For V2 indexing and the VSA, an individual index is now created in the index directory for each of the virtual machines. Whereas in traditional V1 indexing, only one index is used for the entire VSA subclient. 

VM-Centric Operations Benefits

There are several benefits to VM-centric operations like a significant improvement to performance, new robust options and tasks, and an increase in granular control over the management and retention of saved data.

Some key enhancements are described next, but for further details about VM-centric operations, click here.

VM-Based Backups

The VSA backup now has a parent backup job that spawns an additional child job for each VM being protected. For instance, if there are 100 VMs to protect, the parent job launches 100 child jobs. Each child VM job has its own Job ID number and media information making it completely independent of the parent VSA backup job. This split concept is an important change that introduces new capabilities to the VSA which were previously unavailable. For instance, backup jobs are now controlled independently. For example, you can kill a backup job for a single virtual machine without killing the entire VSA subclient job – which would collaterally kill other VMs jobs.

VM-Based Synthetic Fulls

Just like VM-based backups split the VMs into independent jobs for both full and incremental backups, the synthetic full backups have also been enhanced. Commvault^® software automatically creates individual jobs for each virtual machine in the subclient and distributes those jobs among the available proxies. This enhances the overall performance compared to the V1 indexing-based synthetic full backup job. This process is just like multi-stream synthetic fulls for a VSA that is built by allocating one stream per VM.

When testing V1 and V2 indexing, there was a significant performance increase in VSA synthetic full backups. With a V1 indexing test scenario, a synthetic full of 852 VMs completed within 14 hours and 30 minutes. With V2 indexing, that same data set was protected using multiple streams within 4 hours and 20 mins.

VM-Based Priority Ranking

With priority ranking you are able to configure a higher/lower priority for each individual virtual machine, which is used to prioritize the VM protection order during a VSA backup operation. This supersedes the backup operations dispatch logic. For instance, if a user changes the priority of a smaller VM, Commvault^® software elevates that smaller VM to the top of the list over larger VMs, if needed.

When individual priorities are set for the VMs in a subclient, the virtual machines in the subclient are processed in order of priority. This expands the capabilities provided to end-users as it permits those VMs defined as critical to be protected first and committed to media even before the entire virtual server backup completes all other VMs.

NOTE: You can customize the Commcell^® console view to show virtual machines within the display. After you locate the desired VM, you can locate the priority within the VM's Properties and Job Configuration tab.

VM-Based Extended Job Retention

For each virtual machine client, you can redefine the retention of individual backup jobs for a specific virtual machine. This provides the administrator with the ability to selectively extend the life of individual VM-based backup jobs as opposed to having to retain entire VSA backup jobs. Extending VM-based backup jobs are defined within the same Storage Policy copy or defined by an Aux Copy of the individual VM's backup jobs.

Oftentimes administrators are asked to retain entire VSA-based jobs which could have hundreds of VMs and terabytes of data. This request may be due to the retention of a 20 GB virtual machine that the legal department needed for their year-long court case. Considering the multiple impacts TBs to GBs could have on their backend, administrators will appreciate this level of granular control. 

VM / Job-Based Deletion

Commvault^® software now ages or deletes VM jobs from the backend without having to affect the entire VSA client and all of the protected VMs within its backup history. This provides administrators with the granular ability to prune off individual VMs mid-cycle without deleting the entire job/cycle of the virtualization client. In previous versions, administrators had to delete terabytes of data and hundreds of VMs just to delete a single 20 GB VM from the backend.

Reporting against Specific VMs

Now that VM-centric logic divides and protects VMs at a granular level, you now have more granular reporting capabilities. This means that you can report on an individual VM as opposed to an entire virtualization client.