-
Notifications
You must be signed in to change notification settings - Fork 929
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent custom block volume sharing #13183
Prevent custom block volume sharing #13183
Conversation
0488bfa
to
087ec55
Compare
28a7e15
to
e7b3abb
Compare
e7b3abb
to
ecf80be
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly just nits and small tweaks to address.
Heads up @ru-fu - the "Documentation" label was applied to this issue. |
e1dbfa5
to
1ab84a8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you can create block volumes and attach them to profiles in the main test suite we should have a check for that in this PR too.
Also please can you add a check to https://github.com/canonical/lxd-ci/blob/main/tests/storage-volumes-vm for per-VM disk devices.
a6b885b
to
60b18a7
Compare
@tomponline Requested changes made and pushed |
60b18a7
to
ea842ab
Compare
doc/explanation/storage.md
Outdated
@@ -154,7 +154,7 @@ Each storage volume uses one of the following content types: | |||
You can create a custom storage volume of type `block` by using the `--type=block` flag. | |||
|
|||
Custom storage volumes of content type `block` can only be attached to virtual machines. | |||
They should not be shared between instances, because simultaneous access can lead to data corruption. | |||
By default they can only be attached to one instance at a time, because simultaneous access can lead to data corruption. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By default they can only be attached to one instance at a time, because simultaneous access can lead to data corruption. | |
By default, they can only be attached to one instance at a time, because simultaneous access can lead to data corruption. | |
Set the `security.shared` storage option to allow sharing volumes between instances. |
doc/explanation/storage.md
Outdated
@@ -154,7 +154,7 @@ Each storage volume uses one of the following content types: | |||
You can create a custom storage volume of type `block` by using the `--type=block` flag. | |||
|
|||
Custom storage volumes of content type `block` can only be attached to virtual machines. | |||
They should not be shared between instances, because simultaneous access can lead to data corruption. | |||
By default they can only be attached to one instance at a time, because simultaneous access can lead to data corruption. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, missed your comment Tom! But yes, adding that here makes sense. Unfortunately we can't link to the option since it's specific to the storage driver. :(
doc/explanation/storage.md
Outdated
@@ -154,7 +154,7 @@ Each storage volume uses one of the following content types: | |||
You can create a custom storage volume of type `block` by using the `--type=block` flag. | |||
|
|||
Custom storage volumes of content type `block` can only be attached to virtual machines. | |||
They should not be shared between instances, because simultaneous access can lead to data corruption. | |||
By default they can only be attached to one instance at a time, because simultaneous access can lead to data corruption. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the profiles, I don't think it's needed here (because it's implied by saying they can only be attached to one instance). So it makes sense to add it to the how-to like you did.
Signed-off-by: Thomas Hipp <thomashipp@gmail.com> (cherry picked from commit b8d3d735dffe6c587ed0b8965288122f63dfc108) Signed-off-by: hamistao <pedro.ribeiro@canonical.com> License: Apache-2.0
The `Update` function returns `map[string]Device` values despite there being a `Devices` type which is the same thing. This commit changes the return types to be `Devices` instead. Signed-off-by: Thomas Hipp <thomashipp@gmail.com> (cherry picked from commit 6fff607f8462237843a590751d7afcb38335e3f4) Signed-off-by: hamistao <pedro.ribeiro@canonical.com> License: Apache-2.0
Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
This validates shared custom block volumes. Such volumes can be attached to profiles only if `security.shared` is `true`. Also, they can only be attached to more than one instance if `security.shared` is `true`. Signed-off-by: Thomas Hipp <thomashipp@gmail.com> (cherry picked from commit 78315b5d6d8b1783604b482dec5c210767597098) Signed-off-by: hamistao <pedro.ribeiro@canonical.com> License: Apache-2.0
This handles the `security.shared` config key update. If a shared custom storage block volume is attached to a profile, this volume cannot be un-shared. Furthermore, if such a volume is attached to more than one instance, it also cannot be un-shared. Signed-off-by: Thomas Hipp <thomashipp@gmail.com> (cherry picked from commit 29b45bb029d3a447e80a3e6f20e19658183ffb36) Signed-off-by: hamistao <pedro.ribeiro@canonical.com> License: Apache-2.0
Signed-off-by: Thomas Hipp <thomashipp@gmail.com> (cherry picked from commit 6e4e6b6b2061ad719ec576ee143e20f1b208b411) Signed-off-by: hamistao <pedro.ribeiro@canonical.com> License: Apache-2.0
Signed-off-by: Thomas Hipp <thomashipp@gmail.com> (cherry picked from commit 606b833d1a67a3d8bc3e7cec032889c372229242) Signed-off-by: hamistao <pedro.ribeiro@canonical.com> License: Apache-2.0
Signed-off-by: Stéphane Graber <stgraber@stgraber.org> (cherry picked from commit 32a4beecbf8098fdbb15ef5f36088956922630f7) Signed-off-by: hamistao <pedro.ribeiro@canonical.com> License: Apache-2.0
This check is not for when the path property is missing, but to check if a device that is not a root disk (and therefore its path is different from '/') has a source property defined Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
Signed-off-by: hamistao <pedro.ribeiro@canonical.com>
ea842ab
to
911b153
Compare
@ru-fu Thanks for the suggestions, the changes were made. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docs looks good. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
We discussed this and because it will only affect custom block volumes that are actively shared with multiple VMs already, this is likely very niche (due to the risk of data corruption) and thus we would expect the operator to update the volume with security.share=true if they really intend to do this.
Closes #12254.
Changes mostly based on lxc/incus#467 and lxc/incus#529.
This creates the
security.shared
config key for block volumes and adds checks for it during device creation and instance start.This also includes checks for path definition when adding custom volume devices to profiles (filesystem volumes require a path and block volumes don't) and does some refactoring on the
validateConfig
function to make the disk validation process more readable.