Change Cloud - Feature Improvements

Infrastructure
, , ,
1

It would be nice if using CloudEndure to restore an AWS EC2 in another region during a DR scenario that we could then use the “Change Cloud” feature to migrate the server in Morpheus to replace the discovered server record in the DR region that we’re switching to while the primary region is down. Then to use the feature again to migrate the server back to the original cloud after the primary region recovers.

Here are the reasons we would like this for our use case:

  1. CloudEndure simply restores an AWS EC2 in a specified region, so it will be discovered as an “Unmanaged VM” in Morpheus meaning we would need to convert to managed and update the agent API key in the agent configuration each time for hundreds of instances.
  2. Currently, when we restore an instance from AWS Backup to the DR region using blueprints with an AMI Image ID we have to update the AMI Image ID with the latest backup that was taken before we can restore the most recent backup which is taken every few hours. If we use CloudEndure as our backup / restore solution instead it backs up data continuously which provides a more current restore point and even a more granular restore point if we needed to go back to a point in time.
  3. When we restore from a blueprint the new instance / server gets a new agent API key in the DR region which is fine when the Linux Morpheus Agent is installed over the previous agent because it updates the API key and starts the agent during the Cloud-Init. However, when you try to do this for a Windows instance the agent installation fails during Cloud-Init because it doesn’t update the API key so when the agent server restarts it can never communicate properly with Morpheus. This issue already has a support case and should be fixed in the future.

Here are the blockers with the current implementation of the Change Cloud feature:

  1. When we discover an unmanaged VM (VM-B) in the 2nd region and use the Change Cloud to move an existing VM (VM-A) from region 1 to region 2, VM-A gets moved to the 2nd region according to Morpheus, but when you view infrastructure → hosts → virtual machines the record for the VM-B remains in addition to the new record for VM-A in region 2.
  2. The IP address doesn’t change in VM-A to the IP of VM-B.