Okay, according to the BZ comment [0], it's expected that libvirt doesn't know how to detect the CPU model on AArch64. And in the past, it was wrongly being reported by libvirt, which was a bug in libvirt.
So, it seems since they fixed the bug, it breaks in nova now (because nova expects CPU model to be in the XML). When it was erroneously there, things worked. Now that it's gone, things don't work.
To fix it, I think we need to add something like this at [1]:
# Libvirt doesn't know how to detect the host CPU model on AArch64.
if cpu.arch == fields.Architecture.AARCH64:
LOG.debug('Libvirt doesn't know how to detect the host CPU model on AArch64. Skipping CPU comparison')
return
We need to double-check with someone like kashyap to confirm whether there's a more correct way to handle it other than bypassing it altogether.
Okay, according to the BZ comment [0], it's expected that libvirt doesn't know how to detect the CPU model on AArch64. And in the past, it was wrongly being reported by libvirt, which was a bug in libvirt.
So, it seems since they fixed the bug, it breaks in nova now (because nova expects CPU model to be in the XML). When it was erroneously there, things worked. Now that it's gone, things don't work.
To fix it, I think we need to add something like this at [1]:
# Libvirt doesn't know how to detect the host CPU model on AArch64. Architecture. AARCH64: debug(' Libvirt doesn't know how to detect the host CPU model on AArch64. Skipping CPU comparison')
if cpu.arch == fields.
LOG.
return
We need to double-check with someone like kashyap to confirm whether there's a more correct way to handle it other than bypassing it altogether.
[0] https:/ /bugzilla. redhat. com/show_ bug.cgi? id=1430987# c2 /github. com/openstack/ nova/blob/ 8b6b65f/ nova/virt/ libvirt/ driver. py#L6761
[1] https:/