Copying App Volumes AppStacks Between Environments That Use vSAN Storage
Article ID: 326593
Updated On:
Products
Issue/Introduction
There is an issue copying App Volumes AppStacks (VMDK files) if using Secure Copy (SCP) from one environment to another when using vSAN storage. This is not an App Volumes problem; it is related to the way vSAN stores VMDK data.
Clients will often want to create AppStacks in a test environment, then copy those AppStacks to a production environment, and finally import them into App Volumes. In situations where any of those environments use vSAN storage, you will not be able to copy (SCP) AppStacks (specifically VMDK files) between environments.
The VMDK files created by App Volumes are nothing special and are traditionally comprised of two files.
What we normally identify as .vmdk is a type of header/metadata file. Meaning it only holds information regarding the geometry of the virtual disk and, as such, references a file that contains the actual data.
The file referenced is often called a “flat” file; this file contains the actual data of the VMDK. We can identify this file as it has the naming pattern of -flat.vmdk
On traditional block level storage these two files are normally stored together in the same folder, as shown in the example screenshot below.
The vSAN storage is different. If you look at the contents of the “header” file you see something similar to the screenshot below. In this screenshot, the section in red is normally a reference to a “flat” file (example: Adobe_Acrobat_Reader -flat.vmdk). In the case where vSAN is the storage platform, the descriptor file points to the backing vSAN object which contains the data. The screenshot below shows a reference to a VSAN object.
VSAN storage employs object-level storage, which is different from traditional block-level storage. The vSAN objects are managed through a storage policy which, for example, can allow for greater redundancy for some virtual machines over others. Because the reference in the VMDK file points to a vSAN DOM object, it cannot be copied through traditional means (SCP).
To work around this issue you will need traditional block-level storage which acts as a “middle man” to allow the SCP copy of VMDK files between environments. You will also need SSH access enabled on one host in each environment.
The first step is to clone the VMDK you wish to copy from the vSAN volume to the traditional storage volume. Once on traditional storage you will be able to copy (SCP) the two VMDK files directly to a host in a different vSAN environment. After you have copied (SCP) the VMDK files to a destination vSAN environment, you will need to perform a clone action to re-integrate the VMDK with vSAN as a storage object, so it can be protected properly with vSAN.
The diagram below is an overview of the process to copy AppStack (VMDK) files between vSAN environments.
The example below shows the commands required to copy an App Volumes AppStack (VMDK) between environments that use vSAN storage. Before executing these commands you should create a staging area in each environment where AppStacks will be copied temporarily before being copied between hosts for getting re-integrated in the destinations’ vSAN storage.
For example:
In the source environment, create the folder /AppVolumes_Staging
In the destination environment, create the folder /cloudvolumes/staging
Environment
Resolution
Upload Files or Folders to vSAN Datastores
Download Files or Folders from vSAN Datastores
Feedback
