ESXi - Storage Containers/Datastores and vMotion Operation Limits

  • 22 May 2019
  • 2 replies

Userlevel 1
Badge +1
We are planning a major migration from existing 3-tier ESXi over to Nutanix/ESXi (AHV to come later). Due to time constraints in our move, we are trying to optimize how many VM's can migrate at one time. VMware has a few well-known limits on their operations:

vMotion operations per host (10Gb/s network) - 8
vMotion operations per datastore - 128
Storage vMotion operations per host - 2
Storage vMotion operations per datastore - 8

If I take a "one storage container to rule them all" approach, I will be limited to 8 migrations at once, as long as I spread out my migrations to 4 hosts. My target will be a 14 node cluster, so I would like to push up to 28 operations, if at all possible. Would it be considered a best-practice to carve out 4 storage containers, knowing I'm still in the same pool, and fan out the migrations to get around these limits?

My goal is to saturate my 10Gbit inter-datacenter link. Yes, I like to push the limits (break things?). Would the multi-datastore/container approach be advisable here?

Target Nutanix Cluster - 14 node NX-8155-G6 Hybrid


Best answer by RichardsonPorto 22 May 2019, 21:37

View original

This topic has been closed for comments

2 replies

Userlevel 3
Badge +5
Hi @BlakeRobertsNBL

Nutanix recommends having single storage pool with a single storage container unless there is a specific reason to have multiple storage containers, like container with different data reductions features enabled or encryption.

In your case, you will create different container just to allow more than 8 simultaneous storage vMotion which I believe will not be a problem, but after finish the migration, you may can consider consolidate all migrated VMs in a single storage container and delete the other 3.
Userlevel 1
Badge +1
Yes, after the migration, we would plan on reducing down to a single storage container, especially considering we will be investigating a conversion to AHV after the migration.

We just wanted to make sure that creating multiple containers to workaround VMWare's limits would be a viable option without cratering the cluster/storage pool.