Just after an upgrade to Commvault 2023E, that error appears for some VMware backups : " Template VM is not supported for Intellisnap. "
Hello,
2 days ago we performed an upgrade from Commvault 11.28.131 (2022E) to 11.32.76 (2023E) on a Windows 2019 server. Everything went fine, no errors. Immediately after that, during nightly backups, we noticed an unexpected behavior, Commvault issued some errors on VMware VMs backup jobs (done with Intellisnap). Commvault is trying to backup some but not all VMware Linux template and the job completes fine for others VMs, and with the following error for the templates: " Template VM is not supported for Intellisnap. "
The whole VMware infrastructure is hosted on NetApp 9.12.1P11 clusters. Datastores are added in the subclient content.
Any ideas on the origin of this issue ? Thanks in advance.
Page 1 / 1
Hi @RC23 ,
Good day!
VM template backup is not supported in intellisnap using SAN transport mode
Transport mode for VMware is set to “ Auto “, our VMware infrastructure is fully based on NFS. It used to work for years before that upgrade and we did not changed anything in the configuration since then…
In the configuration of the “ defaultBackupSet “, on the VM Filters tab we added an entry to exclude templates, this parameter is in place for ages and worked perfectly well until we upgrade from 11.28 to 11.32:
This property is of course inherited at the subclient level:
We also added a tag in order to be able to exclude specific VMs from backups. This, as well, woks fine. → If I add this tag manually to the template at VMware level, then Commvault exclude the template from the backup.
→ Theoretically, I should NOT be forced to add this tag to the template, the VM Filter should do the job, and it still does for most the virtual clients/subclients… But it looks that only for some subclients this filter is simply ignored by Commvault since we are running 11.32 release, why ?
Thanks in advance for any help. Regards.
Hi..
When doing a “Preview” within the subclient content do the Templates get filtered out as expected and do not show?
/RubeckDK
Hello,
Thanks for the tip.
I had a look at the “ Content “ tab of each involved subclient (3), and clicked on the “ Preview “ button. For all of them, templates were displayed despite the fact that the VM filter is configured at the “ defaultBackupSet “ level. Each subclient is coming from a different virtual server.
→ I removed that filter on all 3 defaultBackupSet and re added it again, then for 2 out of 3 impacted subclients it permits to display the right content, I mean templates were no longer displayed and the total of VMs to backup is equal to what is was before the upgrade. → That’s a good point, even if it does not means that backups will complete tonight without any error … I will check that tomorrow morning.
But unfortunately, there is one remaining subclient for which deleteing/adding the VM filter at the defaultBackupSet level does not solves the issue. → However, if I remove the VM filter at the defaultBackupSet level and add it expressly at the subclient level, then the preview shows the right total of VMs to backup !
Weird...
Could you try to add this additional setting onto the VSA(s) involved in scheduled backup jobs?
I've had issues with discovery in v11.32 as well..... when VMs were excluded on a backupset level some were still included and backed up??!
According to support this is due some caching mechanism which wwas intrudused into v11.32... The above setting disables it.
/RubeckDK
I am a bit lost… This additional setting must be configured at the Commvault server level, like this ?
Or somewhere else ? Please note that this setting is no resolved when I click on “ Lookup “ button.
Thanks in advance for your help.
Being lost is part of working with Commvault…. So no worries… ;-)
Here’s what I would do for testing:
- Create a Client Group - Add the additional setting to the group. - Add your VSA servers (The ones having the Virtual Server Agent installed) to the group. - Kick of the scheduled backup or wait for it to start auto..
I do not think that the key can be “looked up” as it seems a non- public one... .