vRA 7.2 Migrating resources to new business group

[TGrissom]

I'm attempting to migrate resources to new business group, which works fine for resources that don't have any software components. The resources with software components will not migrate. If I use the 'Change reservation of an Iaas Virtual Machine' workflow in vRO, I can get the VM resource to move, but the software components stays on the old business group which then leaves the deployment on the old business group.

Has anyone else ran into this?

[daphnissov]

I've not run into it, but I can see how this wouldn't work. It may not even be a supported action through the UI. There might be some custom vRO work that's possible to accomplish this.

[jasnyder]

Here is what I'm sure is yet another highly unsupported suggestion.  It's something to try at least, in a test environment.  Please do not do this in production.

In my test environment it worked for all deployments including AWS, software components, etc.  This was run against vRA 7.2.

These steps will move all provisioned catalog resources from one business group (AKA subtenant) to another business group.

1. Make sure you have a new busines group properly created with users assigned and a set of entitlements properly created.
2. SSH into the vRA appliance as root
3. su postgres
4. psql
5. \connect vcac
6. SELECT * FROM cat_subtenant;
7. Notate the subtenant_id for the business group you want to migrate from (OLD ID) and the one you want to migrate to (NEW ID)
8. UPDATE cat_resource SET subtenant_id = '[NEW ID]' WHERE subtenant_id = '[OLD ID]';

Example Output:

hwlvra7201:/ # su postgres

postgres@hwlvra7201:/> psql

psql.bin (9.5.4 (VMware Postgres 9.5.4.0-4303132 release))

Type "help" for help.

vcac=# SELECT * FROM cat_subtenant;
	id	|	lastsync	|	name	| tenant_id

--------------------------------------+-------------------------+--------------------+-----------

0240bfef-a08f-4cbc-a212-5c3439967820 | 2017-02-03 00:53:25.863 | tuser1	| MTD
03761b44-7830-4d65-9eda-0819d3ca6fa7 | 2017-10-28 20:12:00.835 | DomainUsers	| MTD

73b5c799-dcab-4dc1-be91-f432fff28929 | 2017-10-28 20:12:00.849 | Lightswitch-Admins | MTD

8ee1fbcf-acf3-42a7-a7c1-4f5b47db84c7 | 2017-10-28 20:12:00.858 | MTD-BG-1	| MTD
31a74d17-a923-49b5-b221-e453465cde60 | 2017-10-28 20:12:00.867 | Developers	| MTD
8cea0f65-1a74-44f6-b3d0-881a6b4138ec | 2017-11-16 00:47:24.435 | Temp-BG	| MTD

(6 rows)

I wanted to move from MTD-BG-1 to Temp-BG, so I grabbed the IDs of those, then ran the update command:

vcac=# UPDATE cat_resource SET subtenant_id = '8cea0f65-1a74-44f6-b3d0-881a6b4138ec' WHERE subtenant_id = '8ee1fbcf-acf3-42a7-a7c1-4f5b47db84c7';

UPDATE 161

vcac=#

I checked my portal and verified that all the resources retained their owner but were moved to a new business group.

Then I decided that I wanted it back the way it was so I ran it in reverse to update everything with the Temp-BG ID back to it's old MTD-BG-1 ID:

vcac=# UPDATE cat_resource SET subtenant_id = '8ee1fbcf-acf3-42a7-a7c1-4f5b47db84c7' WHERE subtenant_id = '8cea0f65-1a74-44f6-b3d0-881a6b4138ec';

UPDATE 161

vcac=#

Then I went back to the portal verified everything was back the way it was originally, everything is under MTD-BG-1 and nothing is under Temp-BG.

Again, I can't stress enough how unsupported direct changes to the DB are.  Do this at your own risk.  Maybe it's a good learning exercise ;- )