A specified parameter was not correct: searchSpec

[raugustine]

I have a customer running Veeam 9 with vSphere 5.1. We started doing replication for them, seeding the replication with backups from Veeam 9. A handful of the VMs were getting an error that prevented them from being replicated: "Processing (vm name) Error: A specified parameter was not correct: searchSpec". Based off of something I read here, I removed the original VMs from inventory on the source vCenter and inventoried them back in, which did not help. I opened up a ticket (#01728609) and was given Veeam 9 update 1 to install. This also did not resolve the issue.

I ended up having to delete my replica VMs in the target vCenter for the problem machines and replicate them again from scratch. FYI in case anyone else runs into this error, as I did not see anything helpful relating to this exact error on the forums.

[alanbolte]

It sounds like Veeam was having trouble finding a replica file or path, or more specifically, that we were sending a request to your vSphere environment, and it couldn't find what we asked it to search for. Did you check if any files might have somehow gone missing before you deleted your replicas? Is there anything unusual about how you name your VMs (e.g. special characters, especially at the beginning or end of the name)?

[raugustine]

Deleting the replica VMs allowed one successful replication for the problem VMs, recreating the replica. Trying to create a second replication point failed with the same error. I have uploaded my logs to the ticket (#01728609) and will see what support says. To answer your questions, the VMs in question are named with the same convention that successful replication VMs use, no special characters other than a space. Out of 16 VMs, only 6 were failing to replicate. There are three replication jobs, the six VMs that are failing are in two separate jobs, three VMs in each job.

[raugustine]

Support suggested that I move the target replica to a different datastore. I deleted the replica, reran the initial replication to a different datastore (which succeeded), and the second replication attempt failed again with the same result. I have uploaded my logs to the ticket again for analysis.

[raugustine]

The root cause of the issue was that the six problem VMs were created in the format ".xx VM-Name" with a period and the IP address at the beginning of the name. This in turn put the leading period at the beginning of the folder name and all files created for the VM. Putting a period at the beginning of the file/folder name caused the files to be hidden in the ESXi file system, which was causing the issue. The VMs that were replicating successfully had been created without the period at the beginning of the name, but had been renamed afterward to that format. The easiest way to fix this would have been to shut off the VMs and clone them, but I had some space limitations on the SAN in question, and it would have taken a lot longer to clone than rename files. I ended up having to remove the VMs from inventory on the source vCenter, remove the period from the folder name using the datastore browser, use SSH to rename the files in the VM folder with the command (mv ".xx VM-Name.yyy" "xx VM-Name.yyy") (use ls -a to see hidden files), use WINSCP to download the .vmx, .vmxf, .vmdk files and manually edit them to remove the references to path/filename with the period at the beginning, then uploaded the files back into the folder. Granted this is a little more risky than cloning, but I was kind of forced to go this route. I imported the VMs back into inventory, removed the old VMs from the Veeam jobs and added the new ones, mapped my backups and replicas, and kicked off my jobs. The backups and replications had to recalculate the disk digests again, which took a long time due to some of the VM sizes, but both backups and replications completed successfully.

Lesson to take away from this: don't start a VM name with a period.