Arch Linux

Sivert3

Member

Registered: 2011-05-16

Posts: 8

[SOLVED] KVM internal error starting libvirt QEMU HVM guest

After updating the system packages my libvirt managed QEMU HVM virtual machines no longer start, producing the following cryptic error in /var/log/libvirt/qemu/<name>.log

KVM internal error. Suberror: 1
extra data[0]: 0x0000000000000000
extra data[1]: 0x0000000000000030
extra data[2]: 0x0000000000000184
extra data[3]: 0x0000000000000000
extra data[4]: 0x0000000000000000
extra data[5]: 0x0000000000000000
emulation failure
RAX=0000000000000000 RBX=ffffffffffffffff RCX=0000000000000000 RDX=0000000000000000
RSI=000000007e8ea798 RDI=000000007efaf898 RBP=000000007ef90ed0 RSP=000000007ef90e48
R8 =0000000000000000 R9 =0000000003041001 R10=000000000000003a R11=000000007e01aa88
R12=000000007ef90ec8 R13=0000000000000001 R14=000000008000f880 R15=000000008000f840
RIP=00000000000a0000 RFL=00010246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
CS =0038 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
SS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
FS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
GS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     000000007e9e0000 00000047
IDT=     000000007e5b3018 00000fff
CR0=80010033 CR2=0000000000000000 CR3=000000007ec01000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d00
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Comparing with a newly made virtual machine that would boot I noticed the machine attribute was pc-q35-7.2 instead of pc-q35-4.2, I edited the xml for the guest to use this value instead. (You can list available machine types with the command qemu-system-x86_64 -machine help)

  <!-- old config -->
  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-4.2'>hvm</type>
    <bootmenu enable='yes' timeout='10000'/>
  </os>
  <!-- new config -->
  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-7.2'>hvm</type>
    <bootmenu enable='yes' timeout='10000'/>
  </os>

But it still wouldn't work, there was no longer a KVM error printed to the log but starting the guest and connecting to the console would reveal a differently formatted but very similar error.

$ virsh start <name> --console
Domain '<name>' started
Connected to domain '<name>'
Escape character is ^] (Ctrl + ])
!!!! X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID - 00000000 !!!!
RIP  - 0000000000030000, CS  - 0000000000000038, RFLAGS - 0000000000010246
RAX  - 0000000000000000, RCX - 0000000000000000, RDX - 0000000000000000
RBX  - FFFFFFFFFFFFFFFF, RSP - 000000007EF90E48, RBP - 000000007EF90ED0
RSI  - 000000007E8EA798, RDI - 000000007EFAF898
R8   - 0000000000000000, R9  - 0000000003041001, R10 - 000000000000003A
R11  - 000000007EFA8478, R12 - 000000007EF90EC8, R13 - 0000000000000001
R14  - 000000008000F880, R15 - 000000008000F840
DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS   - 0000000000000030, SS  - 0000000000000030
CR0  - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000007EC01000
CR4  - 0000000000000668, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 000000007E9E0000 0000000000000047, LDTR - 0000000000000000
IDTR - 000000007E5B3018 0000000000000FFF,   TR - 0000000000000000
FXSAVE_STATE - 000000007EF90AA0
!!!! Can't find image information. !!!!

And after editing the guest XML to match the XML of a newly created one that would boot it still wouldn't work. Looking at the invocation of QEMU in /var/log/libvirt/qemu/<name>.log I found that it referenced an nvram file and after searching the docs I found that there's a --reset-nvram flag to virsh start. I put the two together and got the following solution to the problem:

$ virsh start <name> --reset-nvram
# Now it works :|

This took me 90 minutes of cursing internally at the screen to figure out, so I'm making a note here in case anyone else bumps into the same issue.