How to properly handle moving a VM 'backed up via VMware backup' to using locally installed client?

Q: does the ‘hiccup’ occur only when using quiesced snapshots?

A: I’m not sure what types of snapshots Commvault is doing.  we don’t change any defaults I’m aware of but I’ll look into it. 

Q: Does the hiccup occur when creating quiesced snapshots through the VMware console outside of CommVault?

A: it probably does, but the “repeatability of the problem” is what gets people to say ‘stop commvault from doing these regularly”.  I believe its a function of both commvault taking backups “after hours” with app teams setting up processing of things ‘after hours” (and thus the server “running hot” when backups occur, which is many apps and processes all doing things when the snapshot occurs.. and something notices it.  similar to a single ‘ICMP/ping packet lost’ some apps so not recover well from a connection issue and thus “cant fix the app, stop the backup thing causing it”.  if it occurred for a normal snapshot then it would be “just be a thing that happens rarely” (I can’t just snapshot their server for fun to test easily).

Also: when we take a snapshot of a server, manually, we don't snapshot the memory and quiesce the filesystem.  We warn app owners that “there might be a connectivity blip when doing this” just to CYA, so it does occur sometimes.

Note: we generally don’t use Vm backps for MSSQL servers that are on VM’s for this same reason: some *external* apps just do not like any type of hiccup caused by the snapshot process the vm backup uses/causes. its not the sql server, its the apps not handling a blip when connected to the sql server.  its easier to just not do vm backups of SQL servers to alleviate all the chasing and researching and troubleshooting to determine ‘it happens regularly… during backups! aha! we found the cause! its all you!” every time some app or script has an error in a log and didn't recover well. 

For the “quiesced snapshots” link: I’ll look into this and our settings. I didn’t originally set any of this up,

For the merge script/workflow link: I found this article and it seemed to be only for VM’s ( like a Vm backup issue, or changes in vmware causing weird client names in commvault” but somewhere in the middle it talks about “regular clients”...hmmm… I’ll read it closer (thanks!). I guess the terminology is just confusing as it just keep referring to VM and vmware naming issues but it appears to also apply to the Vm “client” existing in commvault alongside a “non Vm commvault client of the same same because its backing up a VM that was previously a Vm only client in commvault”. 

Application Aware setting is quiesced.

Crash Consistent is not. 

AppAware is not and uses an installed iDA to capture SQL, Exchange, AD, etc locally

VMware gives CV client information as shortname\FQDN for the client and host names. 

Other naming conventions results in the _1 install. 

If the machine already exists because it was discovered during the VSA backup, you can do a push install using the existing grayed out machine.

If the machine already exists because there is a local install and the configuration is not shortname\FQDN, when the VSA discovers the same machine, it configured with _1 to not overwrite the existing machine as it may not necessarily be the same one.

Thanks for the info!  I’ll spend some time looking into the settings and I did not know this ‘If the machine already exists because it was discovered during the VSA backup, you can do a push install using the existing grayed out machine.’

I guess “VM clients” (Java UI: (ribbon) User preferences → (tab) Client Computer Filter → (checkbox) “Show Virtual Machines”) are just ‘clients’ that were/are virtual machines but since they’re just clients ( in commvaults view) they can be re-used for client backups once taken out of VMware backups (thus saving teh original , proper name). I always thought they were special/reserved somehow just for VMware backups and have been filtering them out of my client views.