ESXi Cluster - VM migration capacity calculations

[virtual9999]

Dear All,

We need to migrate around 50+ VMs from one ESXi Cluster A to another ESXi Cluster B ( Ver 6.X ) in preparation for upgrades. How to ensure that the Cluster B has enough additional capacity to handle additional 50+ VMs.  Specifically, what actual metrics ( CPU/RAM related ) need to be considered ?  Since hyperthreading is enabled, how does it affect the CPU capacity calculations in Cluster B? Any sample calculation is appreciated.

Thanks in advance !

-------------------------------------------

[Giuseppe Imer]

Typically, when I perform a migration like the one you mentioned, rather than looking at metrics, I focus on checking the total memory used by the 50 VMs to be migrated and verifying whether I have the same amount of free memory on the destination hosts. As for CPUs, I calculate the VCPUs of the 50 VMs and check whether I have the same number of free VCPUs on the destination cluster, calculating them with a 3:1 ratio. For example, if I have a server with two physical CPUs and 48 cores, based on the 3:1 ratio, I expect it to be able to provide a maximum of 48 x 3 VCPUs for a total of 144 VCPUs per host. Therefore, the sum of the cluster's available VCPUs minus those already used will give me the remaining available ones, and I clearly expect them to be greater than those required by the 50 VMs to be migrated.

BR

Giuseppe

-------------------------------------------

[virtual9999]

Thank you Giuseppe,

I will be taking the same approach as you mentioned. But regarding the
Memory usage, which metric in Vcenter needs to be used for calculations?
Consumed Host Memory or Active Guest Memory. ? How do you obtain the memory
usage ?

Best Regards


On Thu, 15 Jan 2026 at 7:54 am, Giuseppe Imer via Broadcom <
[e-mail]> wrote:

> Typically, when I perform a migration like the one you mentioned, rather
> than looking at metrics, I focus on checking the total memory used by
> the... -posted to the "VMware vSphere" community
> [image: Broadcom] <https: community.broadcom.com>
> VMware vSphere
> <https: community.broadcom.com vmware-cloud-foundation communities community-home digestviewer?communitykey=c24ac095-2065-4261-a4b5-6de9dade8734>
> Post New Message <[e-mail]>
> Re: ESXi Cluster - VM migration capacity calculations
> <https: community.broadcom.com vmware-cloud-foundation discussion esxi-cluster-vm-migration-capacity-calculations#bm4a87e80c-a267-4cb2-94f3-019bbd5f7049>
> Reply to Group
> <[e-mail]?subject=re:+esxi+cluster+-+vm+migration+capacity+calculations> Reply
> to Sender
> <https: community.broadcom.com vmware-cloud-foundation communities all-discussions postreply?messagekey=4a87e80c-a267-4cb2-94f3-019bbd5f7049&ListKey=eabedc9c-d055-471e-9665-018ed42bdca6&SenderKey=7edc3c6a-0905-490b-aa36-019b9e290796>
> [image: Giuseppe Imer]
> <https: community.broadcom.com network members profile?userkey=7edc3c6a-0905-490b-aa36-019b9e290796>
> Jan 14, 2026 4:52 PM
> Giuseppe Imer
> <https: community.broadcom.com network members profile?userkey=7edc3c6a-0905-490b-aa36-019b9e290796>
>
> Typically, when I perform a migration like the one you mentioned, rather
> than looking at metrics, I focus on checking the total memory used by the
> 50 VMs to be migrated and verifying whether I have the same amount of free
> memory on the destination hosts. As for CPUs, I calculate the VCPUs of the
> 50 VMs and check whether I have the same number of free VCPUs on the
> destination cluster, calculating them with a 3:1 ratio. For example, if I
> have a server with two physical CPUs and 48 cores, based on the 3:1 ratio,
> I expect it to be able to provide a maximum of 48 x 3 VCPUs for a total of
> 144 VCPUs per host. Therefore, the sum of the cluster's available VCPUs
> minus those already used will give me the remaining available ones, and I
> clearly expect them to be greater than those required by the 50 VMs to be
> migrated.
>
> BR
>
> Giuseppe
> -------------------------------------------
> *Reply to Group Online
> <https: community.broadcom.com vmware-cloud-foundation communities all-discussions postreply?messagekey=4a87e80c-a267-4cb2-94f3-019bbd5f7049&ListKey=eabedc9c-d055-471e-9665-018ed42bdca6>*
> *Reply to Group via Email
> <[e-mail]?subject=re:+esxi+cluster+-+vm+migration+capacity+calculations>*
> *View Thread
> <https: community.broadcom.com vmware-cloud-foundation discussion esxi-cluster-vm-migration-capacity-calculations#bm4a87e80c-a267-4cb2-94f3-019bbd5f7049>*
> *Recommend
> <https: community.broadcom.com:443 vmware-cloud-foundation discussion esxi-cluster-vm-migration-capacity-calculations?messagekey=4a87e80c-a267-4cb2-94f3-019bbd5f7049&cmd=rate&cmdarg=add#bm4a87e80c-a267-4cb2-94f3-019bbd5f7049>*
> *Forward
> <https: community.broadcom.com vmware-cloud-foundation communities all-discussions forwardmessages?messagekey=4a87e80c-a267-4cb2-94f3-019bbd5f7049&ListKey=eabedc9c-d055-471e-9665-018ed42bdca6>*
> *Flag as Inappropriate
> <https: community.broadcom.com vmware-cloud-foundation discussion esxi-cluster-vm-migration-capacity-calculations?markappropriate=4a87e80c-a267-4cb2-94f3-019bbd5f7049#bm4a87e80c-a267-4cb2-94f3-019bbd5f7049>*
>
> -------------------------------------------
> Original Message:
> Sent: Jan 13, 2026 04:49 PM
> From: virtual9999
> Subject: ESXi Cluster - VM migration capacity calculations
>
> Dear All,
>
> We need to migrate around 50+ VMs from one ESXi Cluster A to another ESXi
> Cluster B ( Ver 6.X ) in preparation for upgrades. How to ensure that the
> Cluster B has enough additional capacity to handle additional 50+ VMs.
> Specifically, what actual metrics ( CPU/RAM related ) need to be considered
> ? Since hyperthreading is enabled, how does it affect the CPU capacity
> calculations in Cluster B? Any sample calculation is appreciated.
>
> Thanks in advance !
>
>
>
> -------------------------------------------
>
>
>
>
> You are receiving this notification because you followed the 'ESXi Cluster
> - VM migration capacity calculations' message thread. If you do not wish to
> follow this, please click here
> <https: community.broadcom.com higherlogic common unfollow.aspx?userkey=43319400-9c37-4779-9a43-c17b6baced92&sKey=KeyRemoved&ItemKey=5f91b454-249e-447c-9787-019bb94e6003>.
>
>
> Update your email preferences
> <https: community.broadcom.com go.aspx?c=Preferences§ion=email> to
> choose the types of email you receive
>
> Unsubscribe from all participation emails
> <https: community.broadcom.com higherlogic egroups unsubscribe.aspx?userkey=43319400-9c37-4779-9a43-c17b6baced92&sKey=KeyRemoved&mClass=Social>
>

[JaeseongLee]

Typically, we compare the host's physical memory capacity with the total memory allocated to VMs.
For example, if you have ten VMs each with 16 GB of memory, the host should ideally have at least 160 GB of available memory.

From my experience, an ESXi host can usually tolerate overcommitment up to around 120% of its physical memory. However, once it exceeds about 150%, VMs start to stall or become unresponsive.

-------------------------------------------

[virtual9999]

Thank You JaeseongLee !

-------------------------------------------

[Giuseppe Imer]

Hi,

Actually, I start with an initial check based on the total memory allocated to each VM, regardless of whether it's using all of it or not, and see if I have the same amount free on the target cluster. This is because if I already have the required resources covered, I don't have to worry about how the VMs are using them. If, however, you're not covered on the target cluster, you need to check the guest memory usage and see if, perhaps by not using all the assigned RAM, you can manage it on the target cluster. However, this exposes you to a more in-depth analysis throughout the day to check the maximum memory peaks for each VM, because that's what you'll need to cover.

BR

Giuseppe

-------------------------------------------

[virtual9999]

Thank you Gluseppe !

-------------------------------------------

[ChrisLeblanc]

I just want to add another factor that I think may start to come into play. 

Microsoft Defender exists for Windows and Linux.  What that it's preferred to have memory reserved.

Current memory calculations I don't think expect reservations.  Just something to think about.

-------------------------------------------