Can't delete Old Replica Listings

[rjhindley]

We recently moved some ESXi hosts to a new vCenter. I am trying to delete some old replicas listings inside the "Backups & Replications > Replicas" view. I have sucessfully deleted the replicas themselves, but I am still left with an empty container within the Veeam "Backup & Replications > Replicas" view which I am unable to delete. If I right-click it and select "Remove from Replicas" or "Delete from Disk", I get an error saying "Host with id (long GUID) was not found" and the listing remains. A minor irritation, I suppose, but it would be nice to clean things up.

Any ideas?

Richard

[Gostev]

You should not be able to delete the Replicas container, it is a persistent tree node. You will see it even right after the clean product install.

[rjhindley]

Apologies - perhaps I was not clear.

It is not the actual container I am trying to delete, it is a particular defunct headings (i.e. Job Names) within the container. E.g. I have a job name labelled "In Use Replication Daily" which contains nothing (i.e. No Replicas), but which is impossible to delete. When I try to delete it, I just get the error " "Host with id (long GUID) was not found".

Thanks

Richard

[Vitaliy S.]

Richard, I believe you should contact our support team to clean these records from the configuration database.

[foggy]

Am I understanding right, that if you select the "Replicas" node to the left, you have an empty record with the job name in the right panel with no actual VMs under it? Not sure how to reproduce this, but it seems that some outside infrastructure changes caused this record to be left alone and if UI refresh/restart does not help, I think you need to edit some DB entries to correct this. I would advice to go with support through this.

[rjhindley]

It happened because we moved the host to a different vCenter - I guess this caused the host GUID to change, and hence the error "Host with id (long GUID) was not found" when we try to delete the record.

[Vitaliy S.]

This makes sense, registering host/VM within a new vCenter Server generates new object ID for this object.

[cmdrriker]

For what it's worth, I have the same problem. And I also had moved my esx hosts from one virtual center to another.

[mlinders]

Had the same problem and figured it wouldnt be too hard to trick the system to remove the stale Replica listings.
I used the following procedure to remove the old replica's:

What we need:
- SQL Management Studio 2008 R2 Express (since we need to mess with the database).
- VMware vSphere client

The ID that Veeam is nagging about. For this example:
fea4d0ec-082b-475e-a724-b33c29496a0a

Use VMware vSphere client to add another VMkernel for management traffic to one of your hosts. It is only temporary since we are going to delete it after we fixed Veeam.
Give this VMKernel an IP address that your Veeam server can connect to (in this example 10.0.10.2)
Add the server to Veeam using this new IP address: 10.0.10.2

Use SQL Management Studio to connect to the Veeam database.
- Open the database: "VeeamBackup"
- Select "dbo.Hosts" under "Tables"
- Right click and select "Show top 1000 Rows"

- Find the above IP 10.0.10.2 that we just added. It will show the IP under Name if you added it to Veeam by IP address. Notice the ID...this is the ID Veeam is looking for.
Try to remove your replica and note down the ID Veeam is asking for. Right click dbo.Hosts and select "Edit top 200 Rows". Change the ID of our temp server 10.0.10.2 to the ID Veeam is asking for. (e.a. fea4d0ec-082b-475e-a724-b33c29496a0a) P.S. Dont forget to <ENTER> after entering the ID and use "Right Click -> Execute" to save the changes.

Now remove your stale Replica's.

Finally:
- Remove the temp server 10.0.10.2 from Veeam
- Remove the temp VMkernel from Vsphere
- All should be fixed again. Enjoy

[Vitaliy S.]

Hi Mark, thanks for sharing your resolution, but please note that we do not recommend to perform any direct SQL database interactions.

[mlinders]

Hi Vitaliy,

I agree that interacting with the SQL database is not something I would recommend doing too often. The above "workaround" is for this specific scenario only and would beat reinstalling Veeam in total. Logging a support case with Veeam would be the proper way for the less daring (read smart people) among us.

It would be better if a future patch will prevent the situation from happening all together. Why not give the possibility to remove an Old Replica listing if the host ID doesnt excist in the database. Since the host is not in the database the replica listing is useless by itself. Something for the DEV team i reckon.

Best Regards,
Mark

[foggy]

Mark, I agree that its better to avoid such obsolete things in UI. I've passed this to our QC team and possibly in future versions there will be an ability to remove such records (i.e. no error message in case of deletion attempt).

[cyberfed]

I found the answer to the Host not found. ID [GUID] problem.

Look in your database under the Folder_Host table.
In there you should see the GUID that Veeam is complaining about. Delete the row. Presto problem solved open up Veeam again and you might get an error for ANOTHER GUID, repeat the process until you dont get an error when opening up Veeam.

This worked for us on 6.5 and we are back up and running. We had moved our vCenter server to a new physical host when we encountered the issues w/veeam.

[Vitaliy S.]

Thanks for sharing, but it is highly not recommended to do changes in the database without guidance of our support team.