Live migration with cpu_shared_set not updating CPU pinning

[Artom Lifshitz]

In pre-Train times, when live migrating an instance without a CPU policy (and therefore without a NUMA topology) to a dest with a vcpu_pin_set, or to a dest with a vcpu_pin_set different from the source, the instance's CPU pinning information was not updated.

Now that CPU resources are a thing, and we use cpu_dedicated_set and cpu_shared_set (the version with the new meaning, not the old cpu_shared_set), this is still a problem. IOW, live migrating a VM with no CPU policy and no NUMA topology from cpu_shared_set=0,1 to cpu_shared_set=2,3 will leave it pinned to CPUs 0,1.

[Yusuf Güngör (yusuf2)]

Hi, is there any plan to fix this?

[Christian Rohmann (christian-rohmann)]

We just ran into this issue when live-migrating lots of VMs to new hardware and observed that the cpu_shared_set (vcpu pinning) remained the same, which rendered 70% of the newly available physical cores completely useless.

But keeping the cpuset unmodified during a live-migration also becomes a big issue in heterogeneous environments with machines with lots of cpu cores and some with fewer. Libvirt likely will not accept a cpuset targeting pCPUs that do not exist on the destination host. Not a problem with cores 0-8 pinned. But a VM running on a machine with 256 cores and a corresponding shared set cannot be live-migrated away anymore.