Add a new sev_enabled() function to the libvirt utils to detect that
SEV is required and return True if and only if the following are both
true:
a) the supports_amd_sev instance variable in the host is
true, *and*
b) the instance extra specs and/or image properties request
memory encryption to be enabled.
In this case we know that SEV functionality is required, so tweak the
guest config accordingly in various ways:
- Ensure that the machine type is some q35 variant. If the image had
an hw_machine_type property requesting some other type, an
InvalidMachineType exception will be raised.
- Set the "iommu" attribute to "on" for all relevant devices including
disk / network devices, but excluding input/graphics/video/serial
devices. This is achieved via a new set_driver_iommu_for_sev()
method added to nova.virt.libvirt.designer. In order to test this
thoroughly, beef up the fake KVM guest fixture with extra devices
of each type.
- Add the <launchSecurity> element to enable use of SEV. Two related
configuration values are extracted from domain capabilities and set
on the element.
- Enable memory locking. All the memory pages allocated by QEMU must
be pinned for SEV, which is achieved via <memoryBacking> and <locked />
elements.
blueprint: amd-sev-libvirt-support
Change-Id: Ie54fca066f3333d1d5d18a2c0e8f6c7d5042490b
libvirt/base.py inherits from test_servers.ServersTestBase which
itself mixes in _IntegratedTestBase. _IntegratedTestBase starts
the PlacementFixture so we don't need to do so a second time.
If we do, then the things can get very weird during the test
cleanUp period with misleading exception and requests made to
placement when it seems like placement should already be gone
(because the inner fixture has alread been cleaned up, but not
the outer).
Change-Id: I057a07c8d0b880c8d09fc2e618ce1f7fc885beda
The existing tests for NVMe with Libvirt were using
APIs inside of os-brick rather than making sure that
we are calling os-brick with the right values.
This patch mocks up the factory function instead and
makes sure we call it with the right values, it also
adds a few more things to test if the root helper and
`device_scan_attempts` are passed down through to
os-brick as well.
Change-Id: I067f9e29b4db3bba0601041cf3603b9653a240b9
A new functional test proves that bandwidth allocation is made on the
destination host during the migration and the binding:profile of the
port is updated to point to the destination resource provider.
As a result, migrate_instance_finish has to be un-stubbed in the
NeutronFixture to update the port's binding profile.
blueprint: support-move-ops-with-qos-ports
Change-Id: Ia69dace6d3b395fa113c1382e8eb52c2cc36119d
To be able to test server move operations with ports having resource
request (e.g. bandwidth) we need a bit of work on the functional test
env to be able to create two computes with bandwidth resources.
blueprint: support-move-ops-with-qos-ports
Change-Id: I4ed0381ec3bbcc9c72a7d5c0e232ac7b44241205
During resize the RequestSpec goes from the dest compute to the
source compute and then back to the dest. The previous patch [1] added
service level check for the dest compute. However the source compute also
needs to be new enough so the RequestSpec is passed through it.
Please note that the functional coverage for this api change is in a
later patch [2].
[1] https://review.opendev.org/#/c/680394
[2] https://review.opendev.org/#/c/679019
blueprint: support-move-ops-with-qos-ports
Change-Id: Ib1a73f5e20b6f9a325d8b24d9253a18f2a46db1f
During cold migrate the RequestSpec goes from the dest compute to the
source compute and then back to the dest. The previous patch [1] added
service level check for the dest compute. However the source compute also
needs to be new enough so the RequestSpec is passed through it.
Please note that the functional coverage for this api change is in a
later patch [2].
[1] https://review.opendev.org/#/c/680394
[2] https://review.opendev.org/#/c/655113
blueprint: support-move-ops-with-qos-ports
Change-Id: I09cac780b9ee5b5726874d4e6f895fd0cd4bff8c
During resize and cold migrate the dest compute service needs to update
the port binding based on the re-calculated port - resource provider mapping.
This update happens in finish_resize.
To do that the dest compute service needs to be at least on service level
39.
The calculation is based on the RequestSpec. The RequestSpec is sent
to the dest compute in pre_resize but the dest compute only sends it to the
source compute in resize_instance if the compute rpc api version is at least
5.2. Also the source compute only sends the RequestSpec to the dest
compute in the finish_resize if the rpc api version is at least 5.2. So
migration with bandwidth only works if both compute talks at least 5.2
which means that the min service level is at least 39.
Change-Id: Ia500b105b9ec70c0d8bd38faa084270b825476eb
blueprint: support-move-ops-with-qos-ports
This call accepts keyword arguments, not a dictionary. The dictionary
ends up passed into the 'details' argument, making it True, so the
query returns all nodes instead of just one. Fix it and raise an error
in case it ever repeats.
Closes-Bug: #1843050
Change-Id: If464423b3c5bc05e2b22ff2245828c677b264d15
IronicDriver should be using fields="instance_uuid" when calling Ironic
API via the OpenStack SDK, but instead is using fields="instance_id".
This patch corrects the calls and adds new tests to cover it.
Change-Id: I4b976b7ea60c63ec334b5eb78c1ad7972fbed574
Closes-Bug: #1842989
The combined fixes for the two related bugs resolve the problem where
SIGHUP breaks the nova-compute service. Bump the minimum requirements
for oslo.privsep and oslo.service to make sure these fixes are in place,
and add a reno to advertise resolution of the issue.
This also bumps oslo.utils to match the lower constraint from
oslo.service.
Change-Id: I39ead744b21a4423352a88573f327273e4d09630
Related-Bug: #1794708
Related-Bug: #1715374
The conductor doc is not really end user material,
so this moves it under reference/, removes it from the
user page and adds it to the reference index for internals.
Also makes the contributor page link to the reference internals
since it's kind of weird to have one contributor section that
only mentions one thing but the internals under reference have
a lot more of that kind of detail. Finally, a todo is added so
we don't forget to update the reference internals about versioned
objects at some point since that's always a point of confusion
for people.
Change-Id: I8d3dbce5334afaa3e1ca309b2669eff9933a0104
The CachingScheduler driver was removed in Stein [1] but
there are a couple of comments in the FilterScheduler
driver code that reference conditions from when the
CachingScheduler existed. This removes them to avoid
confusion.
[1] I1832da2190be5ef2b04953938860a56a43e8cddf
Change-Id: If71a7ac7a33dbc45f417368e3e705f444a3e5bd3
SEV work uncovered that test_get_guest_config_machine_type_s390(), a
unit test for nova.virt.libvirt.utils.get_machine_type(), was
misplaced in test_driver.py, so move that to test_utils.py and in the
process extend it to test other architectures.
Also rename three related unit tests of the same get_machine_type()
for increased clarity.
Change-Id: Ib43f96445e7c13f4abc4522f1d3567a4a5499382
blueprint: amd-sev-libvirt-support
A future test in the SEV patch series will require a fake of a fully
configured KVM guest in order to test enabling of IOMMU for relevant
drivers. So extract the fixture factory and the resulting XML out
into fake_libvirt_data.py where it can also be used by
libvirt/test_designer.py.
It is not sufficient to only extract the XML, because parts of the
config do not have parse_dom() implemented and therefore can only be
generated via code rather than by parsing the XML.
Change-Id: I6595d55823e15ef155f8303eb06676494dd0c661
blueprint: amd-sev-libvirt-support
As explained in the SEV spec[0], SEV needs a q35 machine type in order
to bind all the virtio devices to the PCIe bridge so that they use
virtio 1.0 and not virtio 0.9, since QEMU's iommu_platform feature was
added in virtio 1.0 only.
So add an extra check to be run in the API layer whenever SEV is
requested, to ensure that a machine type *outside* the q35
family (e.g. 'pc', or something like 'pc-i440fx-2.11') is not
explicitly selected in the image via the hw_machine_type property.
Since code in the API layer doesn't run on the compute host, at this
stage we can't check CONF.libvirt.hw_machine_type via libvirt.utils.
A subsequent commit will change the libvirt driver to trigger an
extra, later check on the compute node, although if that late check
fails, the best we can do is to fail the operation on that compute
host, in which case it will potentially be retried on another compute
host.
nova's hardcoded default for x86_64 is 'pc' (which in fact matches
QEMU's current default). This means that it will be recommended that
SEV-capable compute hosts have CONF.libvirt.hw_machine_type configured
to include 'x86_64=q35', otherwise attempts to boot SEV guests without
the image property 'hw_machine_type=q35' will fail unpleasantly.
In the future it is expected that both of these defaults will change
to 'q35'[1]. Once that happens, x86_64 images will be bootable
without needing to set either the hw_machine_type image property or
CONF.libvirt.hw_machine_type.
While extending the unit tests for invalid combinations of image
properties, add tests for the case where the 'hw_firmware_type'
property is not specified at all; previously the tests only covered
the case where it was set to 'bios'.
[0] http://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html
[1] https://bugs.launchpad.net/nova/+bug/1780138
blueprint: amd-sev-libvirt-support
Change-Id: Ibf66a0b371685c673644493bf12663dbf71fab6c
If the server has port with resource allocation and the server is
migrated then when the port is bound to the destination host the
allocation key needs to be updated in the binding:profile to point to
the resource provider that provides resources for this port on the
destination host.
This patch extends the migrate_instance_finish() network api method to
pass the updated resource providers of the ports during migration.
Change-Id: I220fa02ee916728e241503084b14984bab4b0c3b
blueprint: support-move-ops-with-qos-ports
Add the 'delete_on_termination' field to the volume attach API to support
configuring whether to delete the data volume when the instance is destroyed.
To avoid upgrade impact issues with older computes, the
'delete_on_termination' field is set in the API rather than when the BDM
is created in the compute service.
Implements: blueprint support-delete-on-termination-in-server-attach-volume
Change-Id: I55731b1822a4e32909665a2872d80895cb5b12f7
Adam Spiers