Migration issues

mir

Famous Member
Apr 14, 2012
3,598
142
133
Copenhagen, Denmark
I have just replaced a node in a cluster from a athlon x4 740 to a Opteron 3350 HE which have caused some issues regarding migration of VM's and CT's in HA mode. The issue is that migration from a node having a Phenom II X6 1045T to the Opteron node works as expected but migration from the Opteron node to the Phenom node will cause the migrating VM/CT to become unresponsive. Even when I open a console to the VM/CT will not give me access to the VM/CT. Trying to shutdown also fails which only leaves back stop and then start the VM/CT. On both nodes a bond is formed over 2 Intel 1GB nics. Both Phenom and Opteron has Intel 82574L PCIe nics.
Emulation used on all VM/CT is KVM64 or KVM32.

Could the above be caused by that the Phenom cpu flags is a subset of the Opteron cpu flags or is this a bug?
 
I have just replaced a node in a cluster from a athlon x4 740 to a Opteron 3350 HE which have caused some issues regarding migration of VM's and CT's in HA mode. The issue is that migration from a node having a Phenom II X6 1045T to the Opteron node works as expected but migration from the Opteron node to the Phenom node will cause the migrating VM/CT to become unresponsive. Even when I open a console to the VM/CT will not give me access to the VM/CT. Trying to shutdown also fails which only leaves back stop and then start the VM/CT. On both nodes a bond is formed over 2 Intel 1GB nics. Both Phenom and Opteron has Intel 82574L PCIe nics.
Emulation used on all VM/CT is KVM64 or KVM32.

Could the above be caused by that the Phenom cpu flags is a subset of the Opteron cpu flags or is this a bug?

I agree that its the cpu flags, what type of cpu are you using for your VM's?
 
kvm32 or kvm64.

When I get home I will try to see if using qemu{32,64} makes a difference.

kvm will add +x2apic,+sep while qemu will not.

Maybe a check should be added to migration task to validate whether cpu flags will be incompatible and warn the user accordingly.
 
kvm32 or kvm64.

When I get home I will try to see if using qemu{32,64} makes a difference.

kvm will add +x2apic,+sep while qemu will not.

Maybe a check should be added to migration task to validate whether cpu flags will be incompatible and warn the user accordingly.

I agree, a check like that would be super handy. Let us know the outcome when trying cpu type "kvm"
 
Ive had that issue between incompatible Xeons with containers, not entirely sure whether thatd apply here, but might be worth checking out.

It turned out the older Xeon doesnt have the 'xsave' flag, so we had to add "noxsave" to the kernel boot line in /boot/grub/grub.cfg on the machines with the newer Xeons to basically dumb them down to the least common denominator
 
Ive had that issue between incompatible Xeons with containers, not entirely sure whether thatd apply here, but might be worth checking out.

It turned out the older Xeon doesnt have the 'xsave' flag, so we had to add "noxsave" to the kernel boot line in /boot/grub/grub.cfg on the machines with the newer Xeons to basically dumb them down to the least common denominator

That even confirms the bug report I posted above. Hopfully that does the trick. Good luck!
 
I looks exactly like my problem and seems to be fixed in 3.13, but kernel >= 3.13 in proxmox will first be when Redhat ships RHEL 8 which is scheduled between 2018 - 2020. A long time to wait;)

As I am about to replace that node with another Opteron I will have solved the issue long before:cool:
 
I looks exactly like my problem and seems to be fixed in 3.13, but kernel >= 3.13 in proxmox will first be when Redhat ships RHEL 8 which is scheduled between 2018 - 2020. A long time to wait;)

As I am about to replace that node with another Opteron I will have solved the issue long before:cool:

Might be worth trying mo's suggestions, pretty much the same thing.