# Similar to my test in comment #7, but with slighly modified XML as in [1]
Start on Xenial, upgrade one by one
At the spot of xx CPU xx I had one of the following:
hm - host model
<cpu mode='host-model'>
<model fallback='allow'/>
</cpu>
hp - host passthrough
<cpu mode='host-passthrough'>
<model fallback='allow'/>
</cpu>
maf - match allow fallback
<cpu mode='custom' match='exact'>
<model fallback='allow'>host</model>
</cpu>
mff - match forbid fallback
<cpu mode='custom' match='exact'>
<model fallback='forbid'>host</model>
</cpu>
Those four modes to some extend mean the same "make it as close to the
host cpu as possible" with slight differences, see [2]. And the "bonus"
that host-model was broken until soon to be released qemu/libvirt
versions.
Adding next release in sources and using "apt-get install -t" I was able
to test qemu/libvirt upgrades one by one.
Testing: hm hp maf mff
LV 1.3.1 / Qemu 2.5 ok ok ok ok
LV 1.3.1 / Qemu 2.6.1 fails by LV 1.3.1 not able to handle virt-2.6
LV 2.1 / Qemu 2.6.1 ok ok ok ok
LV 2.1 / Qemu 2.8 ok ok ok ok
LV 2.5 / Qemu 2.8 fail ok ok ok
All of the rest of the system is still as on Xenial, so we can exclude
other packages.
We can see that "only" host-model regressed, certainly due to the
mentioned changes that it was broken so far.
By that we get to the libvirt code that corey already posted.
That code changed a lot 2.1-2.5.
To some extend it comes down to the check in virQEMUCapsIsCPUModeSupported, but
I need to find the changes that lead to add the "host-model doesn't work"
statement in the xml doc to get more background.
The whole call to qemuProcessUpdateGuestCPU did not exist in 2.1, to some
extend the old check was "qemuProcessStartValidateGuestCPU".
The introduction of the check that now breaks was in 803497a8 that added
virQEMUCapsIsCPUModeSupported which checks against "!!qemuCaps->hostCPUModel".
That in turn
Related changes:
-
http://libvirt.org/git/?p=libvirt.git;a=commit;h=7ce711a30eaf882ccd0217b2528362b563b6d670
(2.3)
-
http://libvirt.org/git/?p=libvirt.git;a=commit;h=803497a8acdc76b9b229bd27d595ec89beed2f3e
(2.3)
I checked that on x86 host-model works with libvirt 2.5.
That means there the qemuCaps hold this flag.
After confirming that known it was "easy" to have a much simpler check.
The capabilities this is checked is like "the guest wants X can the emulator
run X".
Not that is as easy as:
$ virsh domcapabilities --emulatorbin /usr/bin/qemu-system-aarch64 | grep
host-model
<mode name='host-model' supported='no'/>
While
$ virsh domcapabilities --emulatorbin /usr/bin/qemu-system-x86_64 | grep
host-model
<mode name='host-model' supported='yes'>
With that I went back to
libvirt 2.1 on arm and there the whole cpu section was not populated (and as
outlined libvirt did not check against it even if it would be).
I want to check how this is populated and also the commits that lead to
the doc in the xml stating that host-model was flawed before L3.2/Q2.9.
But before knowing better I'd say libvirt is right to reject it if the
emulator bin is not supporting it. I'll update when I have more in a
bit.
[1]: http://paste.ubuntu.com/24233826/
[2]: https://libvirt.org/formatdomain.html#elementsCPU
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1673467
Title:
[ocata] unsupported configuration: CPU mode 'host-model' for aarch64
kvm domain on aarch64 host is not supported by hypervisor
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1673467/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
