Migrating vmdk's to Nutanix Storage containers and 'Clone from ADSF file'

  • 26 June 2018
  • 1 reply

Is it safe to delete the *-flat.vmdk files that I copy over via NFS mounts to Nutanix Storage Container's that are used when creating new VM's and adding the disk as 'Clone from ADSF file'?

I did not want to end up occupying too much disk space for VMWare / ESXi VM's that I migrate over. Many times when Nutanix documentation and education videos talk about 'cloning' it is making a thin clone or 'delta disk' of sorts. In this scenario I am not sure what really ends up happening with the vmdk's that end up within a Nutanix storage container.

1 reply

Over the following days I made a lot of discoveries about this topic. Basically, the answer is yes. After you 'Clone from ADSF file' or 'Clone from Image Service', Nutanix seems to create a new disk for you within whatever storage container you named. If you NFS mount a storage container you can find the hidden .acropolis/vmdisk folder which has uuid's for all of the disks.

To verify exactly where the disks your VM are stored, beyond the uuid/guid for the disk, you run the following command within acli.

acli vm.get include_vmdisk_paths=1

If you look at my terminal windows. The top is where I interrogated a VM about its disk locations. the vmdisk_uuid matches the terminal below where I show the contents of the .acropolis/vmdisk which has the actual disk used by the VM. The reference 'source_nfs_path' shows the origin, but no delta linkage happens between these. After deleting the vmdk used to source the creation of this VM, the VM continued to work properly.

The acli command I used came from this blog by Artur Krzywdzinski Nov 18, 2016.
Nutanix AHV basics – How to find VM disk

This general topic was brought up a year ago within
Move VM between containers AHV

And a moderator, Jon, pointed to
AHV: Moving VMs between containers (Add existing AHV vdisk to Image service)

The surprising bit is that despite how fancy Nutanix is with HA and ADSF; the simple task of moving VM's from Nutanix Storage container to Container is a manual process.

From the KB article accessed on June 28, 2018:
Since currently there is no Storage vMotion equivalent available to move VMs between containers, this KB article provides an overview of the options available and steps required to move a VM to another container.

Perform the following tasks to migrate a VM to another container within the same AHV cluster.
  1. Determine the vmdisk_uuid of each virtual disk on the VM.
  2. Use the Acropolis Image Service to convert the source virtual disk(s) into image(s) on the target container.
  3. Create a new VM and attach disks from the Acropolis image(s) created in Step 2.
  4. Clean-up: delete the original VM once the newly created VM successfully starts with it's disk(s) in the target container.
This process is also useful for the following tasks.
  • Add existing vDisk to image service on the same cluster
  • Convert Disk Bus Type (SCSI IDE)

It was disappointing to see all of these Pool, Container, Group constructs laying there with the first sentence of the KB:
Nutanix recommends that you use a single container in an AHV cluster to simplify VM and image management.

Practical reasons for dividing containers are RF factor differences between say production and development. You may want to migrate images or VMs from the self service portal to production or back into development. All kinds of different performance characteristics exist on a per storage container level. Hopefully, we will see easier VM mobility features introduced soon into future releases. Hope this helps someone on their journey to excellence.