• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 6356 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Agent is orphaned by this Core

mlove
over 6 years ago

We recently did a Core migration of Rapid Recover 6.1.3 to a new server and all is well except for one client.

It's a VMware server running Linux and when I'm in the Core Console, then go to the Vcenter server and +Protected Machine I'm able to find the machine and select it.  Then I get a warning, "Agent is orphaned by this Core".  I click Next and protect it, but it never shows up in the list of protected servers.

The thing is, this is a new server, we've never backed it up with Rapid Recovery before.

I searched the registry of the old Core and new Core and there are no references to that server.

Any suggestions.

Parents
  • +1 over 6 years ago
    No 2 VMs should have the same UUID or the the same agent ID. Until they all have different IDs I wouldn't expect it to behave properly. Also if the the VMs do have the same UUIDs, then it is likely their .vmds have the same disk IDs as well. This is where agent-less will have trouble, it is dependent upon the information provided by VMware, and if you have the same IDs running around inside ESXi, then that is where the system breaks down.

    As far as the product is concerned, the 'easy' fix would be to put an agent on the one that can't be protected.

    The permanent fix would be you'd have to rid yourself of the incidences of duplicate VMware IDs running around.
Reply
  • +1 over 6 years ago
    No 2 VMs should have the same UUID or the the same agent ID. Until they all have different IDs I wouldn't expect it to behave properly. Also if the the VMs do have the same UUIDs, then it is likely their .vmds have the same disk IDs as well. This is where agent-less will have trouble, it is dependent upon the information provided by VMware, and if you have the same IDs running around inside ESXi, then that is where the system breaks down.

    As far as the product is concerned, the 'easy' fix would be to put an agent on the one that can't be protected.

    The permanent fix would be you'd have to rid yourself of the incidences of duplicate VMware IDs running around.
Children
No Data