qemu Windows VM falla si cambio el nivel de SMP

qemu Windows VM falla si cambio el nivel de SMP

Creé una máquina virtual Windows10 usando qemu hace MUCHO tiempo y la he copiado en varios servidores y la he estado usando con diferentes -smpniveles (la comienzo simplemente usando argumentos de línea de comando y solo uso -smp 4o -smp 8o lo que sea) según las capacidades del servidor. Básicamente uso alrededor del 75% de los núcleos de CPU disponibles en el sistema, pero nunca >10. Lo mismo con -mem. Lo ejecuto -snapshotporque solo lo uso para probar la instalación, etc.

Todos mis servidores son x86_64 con Ubuntu 20.04 (QEMU 4.2.1)

Eso funcionó bien, pero necesitaba actualizar la imagen de la máquina virtual de Windows con parches más nuevos, etc., así que lo hice (sin -snapshotobviamente) y funcionó muy bien. Luego copié la imagen de la VM en mis otros servidores, pero anoche la prueba falló en uno de ellos.

Reintentar muestra que cuando esta imagen se inicia en ese servidor, se detiene durante un tiempo prolongado, luego arroja un BSOD con el error "fallo de estado del controlador de energía", luego finalmente se reinicia y parece estar bien después de eso. Sin embargo, esto no es bueno porque cuando finalmente finaliza, todas mis pruebas han agotado el tiempo de espera, etc.

Busqué este error y no encontré mucho. Así que decidí probar cosas al azar :). Lo primero que noté es que si bien tanto mi sistema "en funcionamiento" como el sistema "que no funciona" usan -mem 8G, el sistema en funcionamiento se usa -smp 4mientras que el sistema que no funciona usa -smp 10: el sistema que no funciona es un servidor más grande con más CPU; el final de /proc/cpuinfolos espectáculos:

processor       : 19
vendor_id       : GenuineIntel
cpu family      : 6
model           : 79
model name      : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz

Así que intenté reiniciar qemu en el sistema "que no funciona" -smp 4y ¡he aquí que funcionó! También lo intenté -smp 8y también falló, pero -smp 6funcionó.

Entonces, eso es desafortunado para mí. ¿Alguien tiene alguna idea de por qué podría suceder esto, por qué esta nueva versión de la imagen tendría este problema cuando la anterior funcionaba bien, si hay alguna forma de solucionarlo desde la imagen (cambiar el inicio de QEMU será molesto ya que requiere cambiar muchas secuencias de comandos de prueba en muchas ramas de Git) u otras sugerencias?

Mi línea de salida QEMU es:

qemu-system-x86_64 -enable-kvm -cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
    -vnc 0.0.0.0:5 -pidfile qemu-installer-vm.pid -daemonize \
    -device nec-usb-xhci -device usb-tablet \
    -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 \
    -drive file=win10-x64.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -vga std \
    -net user,hostfwd=tcp::6350-:22 -net nic -name windows \
    -m 8G -smp 10 -snapshot

Si cambio el -smp 10a -smp 4funciona.

Respuesta1

No es una solución, pero puede apuntar a una.

De un antiguo informe de error:
Error 689665: Especificar la cantidad de núcleos de CPU fallidos con el modelo de CPU Nehalem Penryn y Conroe

Causa: algunos modelos de CPU definidos en qemu-kvm tienen un valor de "nivel" bajo (<4). Esto incluye los modelos: Conroe, Penrym, Nehalem.

Entiendo que esto significa que qemu-kvm tiene un límite en la cantidad de núcleos que depende de la arquitectura virtual de la VM.

No sé mucho sobre cómo se define tu VM y no uso qemu, pero probablemente hayas alcanzado uno de sus límites. Es posible que deba experimentar con las versiones de qemu y los parámetros de configuración para lograr un mayor número de núcleos.

información relacionada