L'invité freebsd fonctionne depuis la ligne de commande `kvm`, se bloque avant de démarrer dans virt-manager

J'ai un invité FreeBSD-7 (dans une image disque qcow2) qui fonctionne très bien quand je le lance depuis la ligne de commande avec

# kvm -drive file=freebsd7.disk

Mais une fois démarré à partir de l' virt-managerinterface graphique, il dépasse le chargeur de démarrage de la deuxième étape, puis se bloque. Plus précisément, il se met en "pause" et refuse de rester inactif. Voici une capture d'écran des dernières choses imprimées:

et voici la configuration XML gobbledygook de virsh -c qemu:///system dumpxml freebsd7-vm:

<domain type='kvm'>
  <name>freebsd7-vm</name>
  <uuid>d91ca4d4-96d3-0f2f-1c18-cf4bc366c1ab</uuid>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <os>
    <type arch='x86_64' machine='pc-1.1'>hvm</type>
    <boot dev='hd'/>
    <bootmenu enable='no'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/zack/Boxes/freebsd-7.disk'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:1d:9f:8e'/>
      <source network='default'/>
      <model type='e1000'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <sound model='ich6'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </sound>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Je suis sûr que cela peut être corrigé en modifiant quelque chose dans la configuration, mais je ne sais pas par où commencer.

(oui, l'utilisation d'une version ancienne de FBSD est délibérée)

EDIT: Comme suggéré ci-dessous, passer <vcpu placement='static'>4</vcpu>à <vcpu placement='static'>1</vcpu>permet un démarrage réussi. En outre, l’exécution de la machine virtuelle à partir de la ligne de commande avec plusieurs processeurs produit ce vidage sur incident:

# kvm -smp 2 -drive file=freebsd7.disk
KVM internal error. Suberror: 1
emulation failure
RAX=ffffffff8080e1c0 RBX=000000000009f000 RCX=00000000c0000080 RDX=0000000000000000
RSI=000000000000d238 RDI=0000000000000000 RBP=0000000000000000 RSP=0000000000000000
R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000
R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
RIP=000000000009f076 RFL=00010086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 0000000000000000 0000ffff 0000f300 DPL=3 DS16 [-WA]
CS =0008 0000000000000000 00000000 00209900 DPL=0 CS64 [--A]
SS =9f00 000000000009f000 0000ffff 0000f300 DPL=3 DS16 [-WA]
DS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
FS =0000 0000000000000000 0000ffff 0000f300 DPL=3 DS16 [-WA]
GS =0000 0000000000000000 0000ffff 0000f300 DPL=3 DS16 [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     000000000009f080 00000020
IDT=     0000000000000000 0000ffff
CR0=80000011 CR2=0000000000000000 CR3=000000000009c000 CR4=00000030
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000501
Code=00 00 00 80 0f 22 c0 ea 70 f0 09 00 08 00 48 b8 c0 e1 80 80 <ff> ff ff ff ff e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 99 20 00 ff ff 00 00

Pour ce que je fais avec ça, céder au mono-processeur c'est bien, mais j'aimerais comprendre pourquoi cela ne fonctionne pas. L'image de la machine virtuelle a été installée sous une interface graphique de gestionnaire différente (boîtes GNOME) qui offrait beaucoup moins de contrôle sur la configuration, et en particulier peut avoir donné à l'installateur un environnement à un seul processeur. Est-ce que FreeBSD 7 installe un noyau différent pour les machines à un et à plusieurs processeurs? Est-il possible de changer sans réinstaller?

La kvmcommande utilise des paramètres par défaut, dont l'un n'active qu'un seul vCPU. Nous utilisons plusieurs machines FreeBSD 7.x avec une configuration très similaire à la vôtre, mais avec une version de BIOS différente. Je me demande s’il existe quelque chose dans le BIOS Qemu / KVM que vous utilisez qui provoque la prise en charge du support multiprocesseur de FreeBSD. Comme vous pouvez le voir ici, dès qu’il imprime ces messages, il devrait afficher le nombre de processeurs suivants: http://f.cl.ly/items/1A451g3M1B1p1k1I0m1J/Screen%20Shot%202013-02-15%20at%2005.48 .37.png

Avez-vous essayé de le démarrer à partir de virt-manager avec un seul processeur?

Pour référence, ceci est la sortie pour moi virsh dumpxml test(une machine virtuelle FreeBSD qui fonctionne): https://www.refheap.com/paste/11318

FreeBSD utilise un noyau compatible SMP par défaut depuis novembre 2003 , bien avant la version 7.4.

Comme Andrew, je soupçonne que quelque chose dans le BIOS perturbe le noyau. Le menu de démarrage a plusieurs options, comme le démarrage (IIRC) avec ACPI désactivé. Cela pourrait aider parfois.