live migration AMD Intel

[kovaga]

Hi list, I have recently introduced and joined "AMD Ryzen 7 5800X" to my home prox cluster running on "Intel(R) Core(TM) i5-8400".
I was under assumption, that providing you set the emulated CPU type to KVM64 or QEMU64, the live migration would work, however its not been my case. Pretty much as soon as I migrate the host, it kernel panics. Having searched this forum, I found several reports of people successfully live migrate from AMD to Intel and vice versa.

So I guess the question is, is there anything else, apart from setting kvm64 I can do in order for live migration to work? or are the CPU too different, and my only chance is to cold migrate?

thanks

 

[mira]

There's no guarantee that it will work, but you could try some things.

Make sure you run the latest version with the 5.11 kernel. And also make sure you're using the latest microcode for your CPUs. See https://wiki.debian.org/Microcode

 

[kovaga]

Hi Mira,

thanks for the hint, unfortunately it didnt work. The VM continues to kernel panics straight after live migration.

I am running the latest 5.11.22-3-pve on both hosts.
The intel cpu runs the updated microcode.
The amd cpu is pretty new, while the latest package with amd microdes is 3.20191218.1, so the microde here remained the same.

 

[mira]

Do you use the latest BIOS version for your mainboard?

 

[kovaga]

Do you use the latest BIOS version for your mainboard?

Good point! Could be the clue

The current BIOS release date on the AMD MB is August 2020
while the release date for AMD Ryzen 7 5800X was November 2020

I will try updating it to the latest one and try again.

 

[ness1602]

Unfortunately for us this doesn't work, intel>Epyc almost always crashes live-migration. But this is okay,since it is known.

 

[kovaga]

Ok, so now the BIOS on both MB is at its latest. It seems that the situation is a bit better, but a random crash can still occur.
What I observed is that idling VM is much less likely to crash, while a VM that is doing "cat /dev/urandom > /dev/null" would crash almost certainly.
So I guess no luck for now.

thanks for the help.