Les processeurs ont beau être “presque” identique , on ne peut pas migrer une machine virtuelle en perdant la capacité “sse4_2” ou “sse4_1” du processeur.

~~READMORE~~

On voit cette capacité la dedans:

# cat /proc/cpuinfo | grep "sse4"
flags           : ... sse4_1 sse4_2 ...

Explication: Au boot, la “libc” détecte la capacité “sse4_X”, et utilise du code spécifique pour optimiser le traitement de certaines fonctions, notamment “strcmp”.

Or, lorsque cette capacité vient a disparaitre suite a une migration, ça plante:

[  160.480144] rsyslogd[1561] trap invalid opcode ip:7f4b52259020 sp:7f4b5029fd58 error:0 in libc-2.13.so[7f4b5213e000+182000]
[  160.480558] invalid opcode: 0000 [#1] SMP

Dans cette situation, soit on change de processeur pour un plus récent, soit on configure le DomU pour qu'il ignore les capacités “SSE4_X”.

Pour cela, il faut jouer avec l'option “cpuid”.

Voici comment “masquer” la capacité “SSE4_1” et “SSE4_2” :

cpuid=[ '1:ecx=xxxxxxxxxxx00xxxxxxxxxxxxxxxxxxx' ]

Dans le même genre, on peut forcer le DomU a voir un pseudo 686 de base avec ceci:

# Downgrade the cpuid to make a better compatibility for migration :
# Look like a generic 686 :
cpuid = [ '0:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0',
          '1:eax=0x06b1,ecx=xxxxxxxxxxx0000xx00xxx0000000xx0,edx=xxx00000xxxxxxx0xxxxxxxxx0xxxxxx',
          '4:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0',
          '0x80000000:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0']

• https://bugzilla.redhat.com/show_bug.cgi?id=694492
• http://zhigang.org/wiki/XenCPUID