Like most IT guys I like to reduce the amount of repeating work where possible. At a customer, we build a VDI/Workspace One staging environment where VDI/RDS templates are built, tested and updated. Also, all VMware App Volumes AppStacks are created on this platform. When the AppStacks are ready for production you want to be able to copy these to the Production storage for App Volumes. For this, there is no proper solution… Either stack those AppStacks again or get them transported with the fling and Veeam. Both of these solutions are time-consuming and try explaining this to the support staff…
To make life easier, I wrote a PowerShell script to properly copy App Volumes AppStacks and it’s metadata from the source datastore to any (shared) datastore. Yes, this includes VSAN! Where you needed to fling and Veeam before to get your AppStacks to your production environment. Manually copying these files via SSH is an option but time-consuming. Copying the AppStacks from a VSAN via the Datastore browser will even end you up with CrapStacks (Broken AppStacks because of something with a .flat file and some VSAN headers that are missing)
The template script I wrote can be downloaded below and requires VMware PowerCLI.
#v1 Added metadata copy option (Download)
#v2 merged metadata copy with AppStack copy. (Download)
#v3 made script variable, only need to change 3 parts. vCenter Server, Source Datastore, and Destination Datastore. (Download)
#v4 Updated with App Volumes 4.0 support! The location of 4.x stacks is different than 2.x and an extra JSON file is needed. (Download)
#1. Change vCenter Address.
#2. Change paths to your source and target datastores.
#3. Set the App Volumes version. 2.x or 4.x. By default, it’s for 4.x.
#4. No Support, know what you are doing and change whatever you like to suit your needs.
Still working on a little bug when using 2.x it will try to copy a matching JSON file but 2.x has no JSON files 🙂 It will work but will give a notice that no JSON file is there to copy.
Current options build in:
“Press ‘1’ To Connect to vCenter.” (Connect to source vCenter)
“Press ‘2’ To List AppStacks Staging.” (List current AppStacks on source datastore)
“Press ‘3’ To List AppStacks Production.” (List current AppStacks on destination datastore)
“Press ‘4’ To Copy AppStacks to Production.” (Copy AppStacks and matching metadata to destination datastore)
“Press ‘5’ To Backup AppStacks.” (Copy all AppStacks to a backup datastore)
“Press ‘6’ To get support.” (No Support)
“Press ‘Q’ To Quit.”
After Copying your AppStacks and Metadata to the target datastore import them on your production App Volumes Manager.
Presto, Your AppStacks are now available on your Productions environment with the corresponding metadata! No legacy status 🙂
Pingback: Virtual Report – We are ITQ | ITQ
Great script, but assumes that both datastores are in the same vCenter. We’re using seperate vCenters for our multi site design, going to see if I can work with yours. Thanks
The same we need, unable to copy with this between 2 difffer env. (vcenters)
Anton, have you resolved that copy between differ datastores please under 2 different vcenters? Whenever I try with this script above I am getting this PS error message “Cannot copy datastore items to a datastore managed by a different VC server.”
See below, we created a NFS datastore which both sites can see, and it replicates to both now.
Pingback: vToolbelt - February 2020 - Cybersylum
Noticed your script doe not work for volumes that have “.” in their name, i.e. application.6.3.0.vmdk.
This script does not seem to be working with vSAN, does not copy the FLAT file.
Will test asap. It did work:(
Hello LaurensvanDuijn, would you ever resolved this script working between 2 differ vcenters? Thanks a lot for your help
Hi, I tried but haven’t got any success yet. It still needs some sort of shared storage between them and it would be a multi-copy action. basically the same as storage groups already do work…
Hi This script is great but the issues i’m coming across is if i do a backup it doesn’t copy the metadata file. Is this by design?
It should but I need to check the script since there is a difference between Appvol 2.x and 4.x with the metadata file.