On Fri, Sep 05, 2025 at 05:09:05PM +0000, Dr. David Alan Gilbert wrote: > k8s used to find it very hard to change the amount of memory allocated to a > container after launch (although I heard that's getting fixed); so you'd > need more excess at the start even if your peek during hand over is only > very short.
When kubevirt will need to support cpr, it needs to do live migration as usual, normally by creating a separate container to put dest QEMU. So the hope is there's no need to change the memory setup. I think it's not yet possible to start two QEMUs in one container after all, because QEMU, in case of kubevirt, is always paired with a libvirt instance. And AFAICT libvirt still doesn't support two instances appear in the same container.. So another container should be required to trigger a live migration, for CPR or not. PS: I never fully understood why that's a challenge btw, especially on mem growing not shrinking. For CPU resources we have the same issue that container cannot easily hot plug CPU resources into one container, that made multifd almost useless for kubevirt when people use dedicated CPU topology, it means all multifd threads will be run either on one physical core (together with all the rest of QEMU mgmt threads, like main thread), or directly run on vCPU threads which is even worse.. -- Peter Xu
