Update git submodules
* Update octavia-tempest-plugin from branch 'master' - Merge "Enable KVM libvirt type on all scenario jobs" - Enable KVM libvirt type on all scenario jobs A subset of nodepool providers have KVM nested virtualization enabled. At present, examples are Vexxhost, OVH, FortNebula and Limestone. We've had a pre-run script for CI to enable KVM when running in one of those providers. This has some drawbacks: 1. With Zuul v3, DEVSTACK_GATE_LIBVIRT_TYPE is obsoleted in favor of LIBVIRT_TYPE in devstack_localrc. 2. The list was outdated (e.g. Vexxhost and FortNebula were not in). 3. Some of the nested virt friendly providers have mixed KVM/TCG servers. 3. Enablement of nested virtualization would require updating of the KVM providers list in our side. When LIBVIR_TYPE=KVM, devstack checks if KVM is really available (via devstack/lib/nova). If it is not, it falls back to qemu (TCG). This check is available since at least Mitaka. Also, some provider nodes expose a generic CPU model. Libvirt matches the named CPU model to the closest from the host. As a result, the matched one may not include the CPUID parameter which seems to be required for nested virtualization. This find-by-match (cpu_mode option in Nova) can be switched "host-passthrough" in which case will cause libvirt to tell KVM to passthrough the host CPU with no modifications. The disadvantage of this mode is guests can only be migrated to an exactly matching host CPU, but we don't need this in CI. Depends-On: https://review.opendev.org/#/c/703324/ Change-Id: I6c4596aa9cc2d7f7703c5acb54fdaed97756788a
This commit is contained in:
parent
f3b8c29e3a
commit
9e2fcad9fb
@ -1 +1 @@
|
||||
Subproject commit b67453f6f0f2f1095bffcdbdf3472b35db8d005d
|
||||
Subproject commit 49460e413bda5eaf1889686d3cfd4d10a8637232
|
Loading…
Reference in New Issue
Block a user