OSSN-0094: restrict swap volume to cinder#574
Draft
grandchild wants to merge 1 commit intostable/2023.2-m3from
Draft
OSSN-0094: restrict swap volume to cinder#574grandchild wants to merge 1 commit intostable/2023.2-m3from
grandchild wants to merge 1 commit intostable/2023.2-m3from
Conversation
This change tightens the validation around the attachment update API to ensure that it can only be called if the source volume has a non empty migration status. That means it will only accept a request to swap the volume if it is the result of a cinder volume migration. This change is being made to prevent the instance domain XML from getting out of sync with the nova BDM records and cinder connection info. In the future support for direct swap volume actions can be re-added if and only if the nova libvirt driver is updated to correctly modify the domain. The libvirt driver is the only driver that supported this API outside of a cinder orchestrated swap volume. By allowing the domain XML and BDMs to get out of sync if an admin later live-migrates the VM the host path will not be modified for the destination host. Normally this results in a live migration failure which often prompts the admin to cold migrate instead. however if the source device path exists on the destination the migration will proceed. This can lead to 2 VMs using the same host block device. At best this will cause a crash or data corruption. At worst it will allow one guest to access the data of another. Prior to this change there was an explicit warning in nova API ref stating that humans should never call this API because it can lead to this situation. Now it considered a hard error due to the security implications. Closes-Bug: #2112187 Depends-on: https://review.opendev.org/c/openstack/tempest/+/957753 Change-Id: I439338bd2f27ccd65a436d18c8cbc9c3127ee612 Signed-off-by: Sean Mooney <work@seanmooney.info>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change tightens the validation around the attachment
update API to ensure that it can only be called if the source
volume has a non empty migration status.
That means it will only accept a request to swap the volume if
it is the result of a cinder volume migration.
This change is being made to prevent the instance domain
XML from getting out of sync with the nova BDM records
and cinder connection info. In the future support for direct
swap volume actions can be re-added if and only if the
nova libvirt driver is updated to correctly modify the domain.
The libvirt driver is the only driver that supported this API
outside of a cinder orchestrated swap volume.
By allowing the domain XML and BDMs to get out of sync
if an admin later live-migrates the VM the host path will not be
modified for the destination host. Normally this results in a live
migration failure which often prompts the admin to cold migrate instead.
however if the source device path exists on the destination the migration
will proceed. This can lead to 2 VMs using the same host block device.
At best this will cause a crash or data corruption.
At worst it will allow one guest to access the data of another.
Prior to this change there was an explicit warning in nova API ref
stating that humans should never call this API because it can lead
to this situation. Now it considered a hard error due to the
security implications.
Closes-Bug: #2112187
Depends-on: https://review.opendev.org/c/openstack/tempest/+/957753
Change-Id: I439338bd2f27ccd65a436d18c8cbc9c3127ee612
Signed-off-by: Sean Mooney work@seanmooney.info