Attach VM root volumes as disk devices #14532
Draft
Conversation
This file contains 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
|
Currently when booting a VM with two root disk devices attached, the kernel chooses which partitions to mount at Still investigating the cause. EDIT: The above scenarios all occurred with |
MggMuggins
force-pushed
the
jira-2160/attach-vm-root-as-disk
branch
from
1a573ed
to
679879e
Compare
|
A little more info on the bootorder bug; this is worse than I thought. When two VMs are launched from the same cloud image, the UUIDs for the filesystems and partitions are all the same: The UUID for the root filesystem is passed via kernel cmdline in Jammy: But TL;DR, VM root volume attachment as implemented here is only safe between machines deployed using different cloud images, using Jammy or older as the recovery machine. Working on figuring out how(/if) the public clouds get around this. |
MggMuggins
force-pushed
the
jira-2160/attach-vm-root-as-disk
branch
from
679879e
to
0c3707d
Compare
|
Done some more reading:
I need to do some more reading on how we control the UEFI boot entries in LXD. More Friday. |
|
In OpenStack, the procedure for getting access to another VM's root volume is to create an image from the VM, a volume from the image, and then mount the volume on another VM: This does suffer from the same duplicate UUID problem as described above. A VM can be created based on the modified volume. |
MggMuggins
force-pushed
the
jira-2160/attach-vm-root-as-disk
branch
3 times, most recently
from
5ec4d3b
to
d3143c7
Compare
MggMuggins
force-pushed
the
jira-2160/attach-vm-root-as-disk
branch
from
d3143c7
to
094830b
Compare
|
converting to draft until TODO items are marked as completed |
Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
These keys can only be live-updated on containers Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
virtual-machine/container volumes in the default project do not include the project name. Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
The change to the source property makes `vol1` and `custom/vol1` semantically identical even though they are not syntactically identical. It's not correct to simply compare the strings anymore. This is the only instance of this in the lxc and client packages. Signed-off-by: Wesley Hershberger <[email protected]>
… used Signed-off-by: Wesley Hershberger <[email protected]>
…tart This allows a VM root disk to be attached to another instance without setting `security.shared`. If we only allow vm roots to be attached when security.shared is set on the volume, it makes it possible to forget to unset security.shared when the volume is detached. Forgetting to unset security.protection.start is harder :) Signed-off-by: Wesley Hershberger <[email protected]>
We can no longer short-circut here because a VM's root disk migt be attached to another instance. I fixed this proactively for containers as well, but it does incur a performance penalty. Signed-off-by: Wesley Hershberger <[email protected]>
...from a virtual machine when the VM's root disk device is attached to another instance. This works when the key is set on a profile or instance, since it checks the expanded config. Signed-off-by: Wesley Hershberger <[email protected]>
Will allow us to check when updating `virtual-machine` volumes Signed-off-by: Wesley Hershberger <[email protected]>
If a virtual-machine volume is attached to more than one instance, don't allow removing security.shared. Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
Signed-off-by: Wesley Hershberger <[email protected]>
MggMuggins
force-pushed
the
jira-2160/attach-vm-root-as-disk
branch
from
094830b
to
729f788
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Includes commits from #14491
This PR enables attaching a virtual machine's root storage volume to another virtual machine via a disk device:
This has some constraints because simultaneous access to storage volumes with content-type
blockis unsafe:vm1's root volume can be attached to exactly one other instance ifvm1hassecurity.protection.start: truevm1's root volume can be attached to any number of other instances if the storage volumevirtual-machine/vm1hassecurity.shared: truesecurity.protection.startis recommended for interactive use; e.g. a user temporarily needs to access a bricked machine's root volume to fix it or recover data.security.sharedcan be used if more than one running instance must have access to the block volume.TODO