Address a TODO from change I8645c31b4ecb18afea592b2a5b360b0165626009.
Change-Id: Iffb174d53ed310257d21f040b90777f41202e202
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The keypair of a server is updated when rebuilding the server with a
keypair. This function has been added since API microversion 2.54.
However the 'keypairs' of the instance object is not saved when saving
the instance object currently.
Make the instance object update the 'keypairs' field when saving the
instance object.
Change-Id: I8a2726b39d0444de8c35480024078a97430f5d0c
Closes-Bug: #1843708
Co-authored-by: Stephen Finucane <stephenfin@redhat.com>
Introduced in libvirt v4.1.0 [1] this error code replaces the previously
raised VIR_ERR_INVALID_ARG, VIR_ERR_OPERATION_FAILED and
VIR_ERR_INVALID_ARG codes [2][3].
VIR_ERR_OPERATION_FAILED was introduced and tested as an
active/live/hot unplug config device detach error code in
I131aaf28d2f5d5d964d4045e3d7d62207079cfb0.
VIR_ERR_INTERNAL_ERROR was introduced and tested as an
active/live/hot unplug config device detach error code in
I3055cd7641de92ab188de73733ca9288a9ca730a.
VIR_ERR_INVALID_ARG was introduced and tested as an
inactive/persistent/cold unplug config device detach error code in
I09230fc47b0950aa5a3db839a070613c9c817576.
This change introduces support for the new VIR_ERR_DEVICE_MISSING error
code while also retaining coverage for these codes until
MIN_LIBVIRT_VERSION is bumped past v4.1.0.
The majority of this change is test code motion with the existing tests
being modified to run against either the active or inactive versions of
the above error codes for the time being.
test_detach_device_with_retry_operation_internal and
test_detach_device_with_retry_invalid_argument_no_live have been removed
as they duplicate the logic within the now refactored
_test_detach_device_with_retry_second_detach_failure.
[1] https://libvirt.org/git/?p=libvirt.git;a=commit;h=bb189c8e8c93f115c13fa3bfffdf64498f3f0ce1
[2] https://libvirt.org/git/?p=libvirt.git;a=commit;h=126db34a81bc9f9f9710408f88cceaa1e34bbbd7
[3] https://libvirt.org/git/?p=libvirt.git;a=commit;h=2f54eab7c7c618811de23c60a51e910274cf30de
Closes-Bug: #1887946
Change-Id: I7eb86edc130d186a66c04b229d46347ec5c0b625
Address comments on I2489bf16dabc8a83b2044139247f4245ae29adb1.
Change-Id: I2f7e5fe4a76fb49870dab8c3816b5c237b773412
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
QEMU < 1.0.3 did not support live snapshots. Bug #1193146 noted that for
this to be used, the version of the QEMU that the instance is running is
important, not the version that it was created with. To test this, it
used a (duplicated) call to 'abort_job' that verified the newer versions
of QEMU was in use. There can't be any instances still in the wild using
this version of QEMU, since those users would have had to update their
OS (the last version of Ubuntu to provide a suitably old QEMU was 12.04
[1], which is very much EOL), meaning a reboot of the host and possible
live-migration of instances to another host, both of which would result
in a newer process.
[1] https://launchpad.net/ubuntu/precise/+package/qemu-kvm
Change-Id: Ic55d2ae49a1ae3aefd986bd1f52c76e022fb8ee1
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Related-Bug: #1193146
In change If6c4dd6890ad6e2d00b186c6a9aa85f507b354e0, we added PAUSED to
a list of power states that aren't valid for live snapshot. This was
necessary to workaround issues with older versions of libvirt and QEMU,
such as those found on Ubuntu 16.04. Our versions of libvirt are now new
enough that this is no longer necessary, so stop doing it.
A confusing (read: wrong) note is removed.
Change-Id: Ife37c2920f2a85eca3401f4b698bc9260277d5a1
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Related-Bug: #1741667
This patch is about to be a follow-up patch to address the
comments of [1], add some notes in introducing the host CPU
usage for an instance with an 'isolate' CPU thread policy.
Also added some other test cases to ensure mixed instance
can reserve proper emulator CPU for hypervisor.
Part of blueprint use-pcpu-and-vcpu-in-one-instance
[1] https://review.opendev.org/716269
Change-Id: I264686705f47713a185536e9d1faa214fc05dafe
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Add the release note for bp/use-pcpu-and-vcpu-in-one-instance.
Part of blueprint use-pcpu-and-vcpu-in-one-instance
Change-Id: I510d7b624d2eb0f9e4e7d07bf1fec4d59a6d2593
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Add the 'dedicated_cpus' section in metadata API service to tell
the instance CPUs that are set as 'dedicated' CPUs if instance
has any dedicated CPUs. If instance is using a 'shared' CPU
allocation policy, it reports 'None' for no dedicated CPU.
Part of blueprint use-pcpu-and-vcpu-in-one-instance
Change-Id: I3d19195ddefb856c10fa6756dd98850119a4dfcb
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Before, realtime CPUs could only be combined with dedicated CPUs
in a 'dedicated' policy instance. This patch supports to create
a type of instance that makes realtime CPUs be mixed with shared
CPUs under the 'mixed' CPU allocation policy.
Part of blueprint use-pcpu-and-vcpu-in-one-instance
Change-Id: Iad7864bf375341ef065bfec229a059e444c910e2
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Enable the 'hw:cpu_dedicated_mask' flavor extra spec interface, user
can create CPU mixing instance through a flavor with following
extra spec settings:
openstack flavor set <flavor_id> \
--property hw:cpu_policy=mixed \
--property hw:cpu_dedicated_mask=0-3,7
In a topic coming later, we'll introduce another way to create a
mixed instance through the real-time interface.
Part of blueprint use-pcpu-and-vcpu-in-one-instance
Change-Id: I2a3311c08a52eb11859c68ef940a0bd755a94c6b
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Bump nova-compute service version, announce the support of
'mixed' instance and then check the service version for all
nova-compute nodes in API layer.
The nova-compute nodes in cluster need to be ensured that
they support the 'mixed' instance CPU allocation policy
once they want to:
- Create a brand-new instance
- Resize to a mixed instance from a dedicated or shared instance.
And we don't support rebuilding an instance that changes
the NUMA topology, and changing the CPU policy will
definitely mean changing the NUMA topology, so nova-compute
nodes version will not be checked when rebuilding.
It is also not necessary to check the service version when
shelving and unshelving an instance, because the instance
CPU policy cannot be changed in this process, and all
compute nodes service have been checked before shelving a
mixed instance, no need to check this again.
Part of blueprint use-pcpu-and-vcpu-in-one-instance
Change-Id: I59298788f26ca8f32bf3e38f3a52f72ff63fcc8b
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
While this is extremely chatty given the 0.5 second loop used by callers
into this method it will provide useful insight into why certain
failures are seen.
Change-Id: I6e58908966a2dc62a3fff155bb81481d68aa2d68
Resolve a TODO from Icc7b3d250bb9dd3d162731959185d9e962727247. The new
function is small enough to fold into its caller, which highlights some
somewhat redundant testing.
Change-Id: I3f146b61d84a73c0fa68be6eb11319be36d18084
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Zuul