Migration requires shut down existing VRO?

[cjanz]

Author :

URL : http:////docs.vmware.com/en/vRealize-Orchestrator/7.5/com.vmware.vrealize.orchestrator-migrate.doc/G...

Topic Name : Migrate an External vRealize Orchestrator 6.x and later to vRealize Automation 7.5

Publication Name : Migrating vRealize Orchestrator

Product/Version : vRealize Orchestrator/7.5

Question :

Want to set up an upgrade environment for testing before moving to 7.5 without shutting down my prod 6.0.5 VRO / VRA instance.  Is this possible?  Migration instructions call for shutting down VRO source instance.

[iiliev]

I suppose the main reason to ask source vRO instance to be shut down before the migration is started is to guarantee that vRO database will remain in consistent/unchanged state during the migration process.

So, even if in theory migration from a running vRO source could work, in practice it is not very clear what will happen with source content that has been created/modified/deleted while the migration process was working. From this perspective, migration from a shut down vRO source sounds safer/more deterministic to me.

[cjanz]

Hmm, I should have been more clear.  I didn't mean that I was unwilling to take the environment temporarily offline.  I meant that once the new instance was running I wanted to turn the old instance back on immediately and have both environments running.  This will enable us to test our workflows in 7.5 and do whatever development or reconfiguration is necessary prior to cut-over.

Is there a guide for which items might be conflicting?

[iiliev · Accepted solution]

I'm not aware of such guide.

For this use case, is it an option to deploy a clean 7.5 environment and then simply create a vRO package with your custom content (workflows/actions/etc), export the package from the current 6.x system, and import it in the 7.5? Or your existing 6.x environment is very big and it will take too much effort to reconfigure the new 7.5?

[cjanz]

Yeah, I think you're right.  Seems like clean install, export and import is the way to go here.

[jauling]

Sorry, I know this is an old thread. We accomplished this slightly differently. Maybe this will help others who are still in the progress of moving to 7.5 or higher.

We took our production vRO 7.2 instance, shut it down, and created a VM snapshot. Then powered it back up. The downtime for creating a clean VM snapshot is way less than having it down for the duration of a vRO migration.

We then created a clone of the production vRO 7.2 instance using the VM snapshot created above. I couldn't find a way to do this via the vCenter GUI, but I found an easy way using PowerCLI:

https://serverfault.com/questions/704581/copy-vm-snapshot-to-a-new-vm-environment

Before I powered on the vRO 7.2 clone, I disconnected its network interface. Then attached to it via VM console. Then you can easily update the network configuration via single user mode. The files I modified were /etc/hosts and /etc/sysconfig/networking/devices/ifcfg-eth0. The vApp parameters for both the production vRO 7.2 and the clone were blank for some reason, so I couldn't use it to change the network config. Once you're happy with the updates, you can take a VM snapshot of the clone in case you screw it up and need to revert. Then power it up. Then you can use the clone as your vRO source for the migration.

I preferred this method since the live production vRO instance isn't involved at all in the migration! I've also toyed with export/import of packages and individual objects, but that was a major headache and too many moving pieces.