• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 6361 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.

  • 0 over 6 years ago

    The first thing that comes to mind is if the machine is a clone of another VM. The Rapid Recovery core will place an ID within the .vmx file of each protected VM. That ID is what RR uses to associate that VM with recovery points, and uses that as the placeholder within the database. The situation you are describing is what would happen if 1 or more VMs share that entry, which commonly happens with cloned VMs.

    This can be corrected by manually changing the ID in the .vmx file of that VM and then bringing it under protection. I believe the entry in the .vmx is: 

    ddprr-apprecovery-agent-id 

  • 0 over 6 years ago
    Unfortunately it's not cloned, but I did check the UUID. We're only backing up 3 VMs this way and it's weird because all 3 have the same UUID, but 2 work and I'm only getting the "Agent is orphaned by this Core" on one of the servers.
  • +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.
  • 0 over 6 years ago
    Thanks. We decided to just put an agent on all 3 since it was just a handful of machines.
    Thanks for replying to me.