vSphere 5: vMotion enhancement
I was reading through this article vMotion Architecture, Performance, and Best Practices in VMware vSphere 5.
I was not aware (perhaps only myself) that ESXi 5 introduces virtual NUMA (vNUMA). What this means that in terms of performance, the ESXi is able to know which is the most efficient way to access the memory. This was not possible in ESXi 4.x.
On reading further, this brought something to me especially for environment who enable EVC with mixed of hardware differences.
ESXi 5 introduces virtual NUMA (vNUMA), which exposes the ESXi host’s NUMA topology to the guest operating systems. When using this feature, apply vMotion to move virtual machines between clusters that are composed of hosts with matching NUMA architectures. This is because the very first time a vNUMA-enabled virtual machine is powered on, its vNUMA topology is set, based in part on the NUMA topology of the underlying physical host on which it is running. After a virtual machine’s vNUMA topology is initialized, it doesn’t change. This means that if a vNUMA virtual machine is migrated to a host with a different NUMA topology, the virtual machine’s vNUMA topology might no longer be optimal for the underlying physical NUMA topology, potentially resulting in reduced performance.
This means, if you are to vMotion across a hardware different, the original NUMA architecture from the source host remains on the VM. And the VM will not be aware of the change unless a power cycle is performed (not reboot) on the VM for performance.
Something interesting to know. Don't you think?
I was not aware (perhaps only myself) that ESXi 5 introduces virtual NUMA (vNUMA). What this means that in terms of performance, the ESXi is able to know which is the most efficient way to access the memory. This was not possible in ESXi 4.x.
On reading further, this brought something to me especially for environment who enable EVC with mixed of hardware differences.
ESXi 5 introduces virtual NUMA (vNUMA), which exposes the ESXi host’s NUMA topology to the guest operating systems. When using this feature, apply vMotion to move virtual machines between clusters that are composed of hosts with matching NUMA architectures. This is because the very first time a vNUMA-enabled virtual machine is powered on, its vNUMA topology is set, based in part on the NUMA topology of the underlying physical host on which it is running. After a virtual machine’s vNUMA topology is initialized, it doesn’t change. This means that if a vNUMA virtual machine is migrated to a host with a different NUMA topology, the virtual machine’s vNUMA topology might no longer be optimal for the underlying physical NUMA topology, potentially resulting in reduced performance.
This means, if you are to vMotion across a hardware different, the original NUMA architecture from the source host remains on the VM. And the VM will not be aware of the change unless a power cycle is performed (not reboot) on the VM for performance.
Something interesting to know. Don't you think?
Comments