Return to Answer

If all the following hold

• More than one CPU in the VM
• The VM is pinned (via the host) to specific dedicated CPUs (not shared with other VMs) with a 1-1 mapping of VM CPUs to host CPUs
• The VM has dedicated (e.g. via passthrough) access to storage/network hardware

then in-VM IRQ rebalancing still makes sense.

Without multiple CPUs within the VM, in-VM IRQ rebalancing obviously serves no purpose. For the other points things become tricky because the "real" CPUs your VM is sitting on can be shuffling around underneath it and the VM's OS doesn't know which of the virtual interrupts are going to be handled by which of the real CPUs. Additionally, if the real CPU is being shared between multiple VMs you don't actually know what other work it is doing or when the virtual CPU is going to get around to being serviced so the "virtual rebalancing" could actually be making things worse...

PS: It will just be /proc/interrupts that you will need to look at.

PPS: Two years ago isn't that old! Some information is timeless...

PPPS: VMCI is vestigial and isn't supported on ESXi 6 or later.

If all the following hold

• More than one CPU in the VM
• The VM is pinned (via the host) to specific dedicated CPUs (not shared with other VMs) with a 1-1 mapping of VM CPUs to host CPUs
• The VM has dedicated (e.g. via passthrough) access to storage/network hardware

then in-VM IRQ rebalancing still makes sense.

Without multiple CPUs within the VM, in-VM IRQ rebalancing obviously serves no purpose. For the other points things become tricky because the "real" CPUs your VM is sitting on can be shuffling around underneath it and the VM's OS doesn't know which of the virtual interrupts are going to be handled by which of the real CPUs. Additionally, if the real CPU is being shared between multiple VMs you don't actually know what other work it is doing or when the virtual CPU is going to get around to being serviced so the "virtual rebalancing" could actually be making things worse...

PS: Two years ago isn't that old! Some information is timeless...

PPS: VMCI is vestigial and isn't supported on ESXi 6 or later.

If all the following hold

• More than one CPU in the VM
• The VM is pinned (via the host) to specific dedicated CPUs (not shared with VMs) with a 1-1 mapping of VM CPUs to host CPUs
• The VM has dedicated (e.g. via passthrough) access to storage/network hardware

then in-VM IRQ rebalancing still makes sense.

Without multiple CPUs within the VM, in-VM IRQ rebalancing obviously serves no purpose. For the other points things become tricky because the "real" CPUs your VM is sitting on can be shuffling around underneath it and the VM's OS doesn't know which of the virtual interrupts are going to be handled by which of the real CPUs. Additionally, if the real CPU is being shared between multiple VMs you don't actually know what other work it is doing or when the virtual CPU is going to get around to being serviced so the "virtual rebalancing" could actually be making things worse...

PS: It will just be /proc/interrupts that you will need to look at.

PPS: Two years ago isn't that old! Some information is timeless...

PPPS: VMCI is vestigial and isn't supported on ESXi 6 or later.

If all the following hold

• More than one CPU in the VM
• The VM is pinned (via the host) to specific dedicated CPUs (not shared with other VMs) with a 1-1 mapping of VM CPUs to host CPUs
• The VM has dedicated (e.g. via passthrough) access to storage/network hardware

then in-VM IRQ rebalancing still makes sense.

Without multiple CPUs within the VM, in-VM IRQ rebalancing obviously serves no purpose. For the other points things become tricky because the "real" CPUs your VM is sitting on can be shuffling around underneath it and the VM's OS doesn't know which of the virtual interrupts are going to be handled by which of the real CPUs. Additionally, if the real CPU is being shared between multiple VMs you don't actually know what other work it is doing or when the virtual CPU is going to get around to being serviced so the "virtual rebalancing" could actually be making things worse...

PS: It will just be /proc/interrupts that you will need to look at.

PPS: Two years ago isn't that old! Some information is timeless...

PPPS: VMCI is vestigial and isn't supported on ESXi 6 or later.

If all the following hold

• More than one CPUs in the VM
• Pinned your VM (via your host) to specific dedicated CPUs with a 1-1 mapping
• The VM has dedicated (e.g. via passthrough) access to storage/network hardware

then in-VM IRQ rebalancing still makes sense.

Without multiple CPUs in the VM, in-VM IRQ rebalancing obviously serves no purpose. For the other points things become tricky because the "real" CPUs your VM is sitting on could be shuffling around underneath you and you don't know which of your virtual interrupts are going to be handled by which real CPUs. Additionally, if the real CPU is being shared between multiple VMs you don't actually know what other work it is doing or when it is going to get around to servicing things so the "virtual rebalancing" could actually be making things worse...

PS: It will just be /proc/interrupts that you will need to look at.

PPS: Two years ago isn't that old! Some information is timeless...

PPPS: VMCI is vestigial and isn't supported on ESXi 6 or later.

If all the following hold

• More than one CPU in the VM
• The VM is pinned (via the host) to specific dedicated CPUs (not shared with VMs) with a 1-1 mapping of VM CPUs to host CPUs
• The VM has dedicated (e.g. via passthrough) access to storage/network hardware

then in-VM IRQ rebalancing still makes sense.

Without multiple CPUs within the VM, in-VM IRQ rebalancing obviously serves no purpose. For the other points things become tricky because the "real" CPUs your VM is sitting on can be shuffling around underneath it and the VM's OS doesn't know which of the virtual interrupts are going to be handled by which of the real CPUs. Additionally, if the real CPU is being shared between multiple VMs you don't actually know what other work it is doing or when the virtual CPU is going to get around to being serviced so the "virtual rebalancing" could actually be making things worse...

PS: It will just be /proc/interrupts that you will need to look at.

PPS: Two years ago isn't that old! Some information is timeless...

PPPS: VMCI is vestigial and isn't supported on ESXi 6 or later.