QEMU/KVM guest kernel panic on legacy CPU

Insight & Feedback
1

I have two ZimaOS installations running, one Intel N100, the other with dusty Celeron J1900.

Release 1.6.2 works flawlessly on the former, but with the J1900 QEMU/KVM app images are freezing on startup by means of guest kernel panic after UEFI.

Some trial & error proved that ZimaOS release 1.6.1 with kernel 6.12 runs without problems, but regardless of Docker or KVM the 6.18. kernel of 1.6.2(-beta) makes the guest images crashing.

There seems to be a known Linux 6.18 related QEMU problem which is linked to ‘CPU migratability setting’, so I am hopeing for ZimaOS with update kernel unless there would be some work around on offer!

2

Your testing strongly indicates a regression introduced with the Linux 6.18 host kernel rather than a problem with the guest image. Similar KVM reports show guests freezing or kernel-panicking when CPU migratability is disabled, with enabling migratability reported as a workaround.

If ZVM provides access to the VM CPU configuration, check whether it is using host passthrough with migratable=off and change it to on . ZimaOS may not currently expose this setting in the interface.

I believe IceWhale should investigate this against the J1900 and either update the kernel/KVM packages or expose the CPU migratability option. In the meantime, remaining on ZimaOS 1.6.1 appears to be the reliable workaround for this hardware.

Could you also post a clear screenshot of the guest kernel panic and the selected CPU model from the VM configuration? That will help confirm whether it matches the known issue.

3

Thanks for your profound reply, @gelbuilding.
Sadly I am not an virtualization expert, need some time to figure VM configuration out.
So meanwhile here is the screenshot at least -

kernel_panic
kernel_panic2316×1378 458 KB

4

Thanks, the screenshot is useful. It confirms the guest kernel is crashing during early boot with:

Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

No problem if you are not familiar with the VM configuration. You have already provided the most important comparison: the same guest works on ZimaOS 1.6.1 with kernel 6.12 but crashes on 1.6.2 with kernel 6.18 on the J1900.

I believe this now needs IceWhale to check the QEMU CPU configuration generated by ZVM and test the kernel change on older Bay Trail hardware. For now, staying on 1.6.1 appears to be the safest workaround.

5

now, found this xml file in the /etc/libvirt/qemu directory, which looks like configuration for the shown porteux OS VM.

There is a line mentioning
arch=‘x86_64’ machine=‘pc-q35-9.2’

but why says <os_type>windows</os_type> ?

The exciting thing is, this same OS image is running on J1900 + 1.6.1 and N100 + 1.6.2 without a hitch!

==============================================================

e1b4110e e1b4110e-8d33-4eae-95cc-83fdae4184d9 porteux 1782022595 windows 4194304 4194304 4 hvm destroy restart restart /usr/bin/qemu-system-x86_64
6

sorry, no attachments allowed, “I’m new to this …”

e1b4110e
e1b4110e2694×1544 329 KB

7

Thanks, that XML clears up an important point.

The windows value is only inside ZimaOS/CasaOS application metadata:

<metadata>
  <x-casaos ...>
    <os_type>windows</os_type>
  </x-casaos>
</metadata>

It does not control how QEMU boots the guest. Libvirt permits applications to store their own information in the <metadata> section. The actual VM type is defined here:

<os>
  <type arch='x86_64' machine='pc-q35-9.2'>hvm</type>
</os>

More importantly, your CPU configuration already shows:

<cpu mode='host-passthrough' check='none' migratable='on'>

So the previously mentioned migratable=on workaround is already enabled and does not resolve this case.

The comparison remains significant:

  • J1900 with ZimaOS 1.6.1 works
  • J1900 with ZimaOS 1.6.2 panics
  • N100 with ZimaOS 1.6.2 works
  • The same PorteuX image is being used

I believe this points more specifically to a Linux 6.18 KVM/QEMU interaction with the older J1900 CPU rather than an incorrect guest operating-system selection.

No problem about the attachment restriction. Pasting the XML as text is enough, and this has already ruled out the migratability setting as the cause.

8

very clear @gelbuilding, your comparison is absolutely correct.

1 Like