On Wed, 2019-07-24 at 09:47 -0500, Matt Riedemann wrote:
On 7/24/2019 9:34 AM, Matt Riedemann wrote:
Massimo - just to confirm, your [libvirt]/virt_type is "kvm" rather than "qemu" correct? If so, then yeah what Melanie found is the problem and was regression in behavior for the ImagePropertiesFilter in Rocky and there should be a fix to the docs and likely a release note - though the release note is tricky since the regression was introduced in Rocky.
Note that the glance description of the hypervisor_type property is also wrong:
https://docs.openstack.org/glance/latest/admin/useful-image-properties.html
"The hypervisor type. Note that qemu is used for both QEMU and KVM hypervisor types."
Given https://review.opendev.org/#/c/531328/ was abandoned, if the API is still showing QEMU for the hypervisor type (which Massimo confirmed it is) even though the node is configured with virt_type=kvm and that's what the ImagePropertiesFilter is going to use, I think we'd be justified in reverting https://review.opendev.org/#/c/531347/ since it's totally confusing to operators if the API is showing the hypervisor_type as QEMU but the scheduler is filtering on "kvm".
the API and the fileters should both see the hyperviors type as QEMU regradles of if the virt type is qemu or kvm.
kvm is just an accleration mechanium for QEMU it is not a sperate hypervior. we stopped progerssing https://review.opendev.org/#/c/531328/ as it was a breaking api change that leaked config info via the api. e.g. the virt_type. we should be consistent however an always report qemu both via the api and to the image proerties filetr for hypervisor_type.
we could have a seperate imemamge metadata for forcing kvm or qemu but as documented in glance hypervior_type should be qemu when the tcg backend is user or the kvm backend. if we wanted to support kvm specificlay i would suggest supporting vm_mode=hvm
We can change the docs but that feels like papering over the issue to me. What would the docs say? Something like, "Since the 18.0.0 Rocky release, the hypervisor_type value for libvirt nodes should match the configured [libvirt]/virt_type value"? That won't fix any existing images with their properties embedded in an instance's system_metadata which could prevent you from being able to migrate those instances anywhere during the upgrade - you'd have to essentially do some database surgery in the instance_system_metadata table to fix the image_hypervisor_type value to match whatever the virt_type value is on that node.
Alternatively we could try to put some targeted compat code in the ImagePropertiesFilter where if the hypervisor_type is QEMU/qemu but the node is reporting kvm, we let it slide and accept that host?