New App Volumes Server - need to have it ignore the old one

[bvi2006]

Hi, 

I have built a new app volumes server so that I can run a parallel environment until I cut over to the new one. It seems that the new one knows there is and old one and wants me to register the new one. But they are in different vcenters, so any registration will not work. 

Can someone help?

Thanks~

[Micheal_A]

Did you build new App Volumes components?

• New SQL DB
• New Data-store locations for New App Volumes instance

[bvi2006]

Hi Michael,

I copied the database from the original and pointed to that during installation. Maybe that is the issue.

I do not have new datastore locations... In fact, I am hoping I can point to that same cloudvolume when I cut over. Or, I can copy them I am guessing? I have not even gotten to the point that I can configure the new one - I am stuck on the register screen.

Thanks for your help!

[sjesse]

Why are you copying the database, if these are seperate environments, they should have seperate databases. Really no reason I can think of to copy it

[bvi2006]

because I am trying to create a complete parallel environment so that I can cut over to the new one in a few weeks and decommission the old one. I am not sure how to move forward to accomplish this. I would want to use the same applications as well - not sure how to do that either other than copying the files to a new directory on the vSAN datastore. Thanks for any help!

[Micheal_A · Accepted solution]

You need to do the following:

1. Delete the new AVM VMs.
2. Delete the copied database.
3. Create New AVM VMs.
4. Create a new instance of AVM DB.
5. Install AVM on first VM and configure to new DB instance.

Now for storage;

You have two scenarios:

Scenario 1:

1. Your current AVM instance is at least 4.5
2. You then step up the AVM default storage to point to the same path as your current AVM datastore path. (DS\appvolumes\packages)
3. Then scan to import all your packages.
4. Run the AVM Entitlement Fling Tool to get your assignments and entitlements applied to new instance.

Scenario 2:

1. Your current AVM instance is less than 4.5
2. You then step up the AVM default storage to point to the a different path from your current AVM datastore path. (DS\appvolumes45\packages)
3. From vCenter, copy current AVM package storage to new storage location.
4. Then scan to import all your packages.
5. Run the AVM Entitlement Fling Tool to get your assignments and entitlements applied to new instance.

[bvi2006]

perfect !!!

Thank you so much, I will use your suggestions and give feedback when I have completed one or the other 🙂 

[bvi2006]

That worked great thanks. The Fling was not happy due to the fact that the servers were in different domains, but I was able to fix them manually in 30 minutes, so no big deal. 

THANK YOU !!!!

[thavener]

I am having the exact same issue HOWEVER I did not copy the DB.  I did create a NEW DB on our SQL Always on Availability Groups according to this TechZone article https://techzone.vmware.com/resource/app-volumes-configuration#create-always-on-availability-groups-...

and pointed the install to that DB.

I can't get the localhost/start-config to run at all.  Also the storage is completely separate.

[thavener]

Trick is apparently to have App Volumes installer create the DB on one of the SQL AG servers and after the AppVol Config is done on that server stop the App Vol Manager Service, Add that DB to the AG Group, then change the ODBC to point to the listener IP of the AG Group, and then start the App Vol Manager Service.  If any one ever needs this.  Subsequent App Vol Managers should be able to point to the listener straight away instead of doing the trick above.