Skip to content
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

Want to be able to use snapshots without changing disk serial number #7153

Open
iximeow opened this issue Nov 23, 2024 · 1 comment
Open
Labels
storage Related to storage.

Comments

@iximeow
Copy link
Member

iximeow commented Nov 23, 2024

it would be nice to be able to replace a disk's contents by a snapshot; currently to use a snapshot you _must_create a new disk. this is great, but a new disk means a new serial number, and means "restore to a snapshot" is a bit lossy.

this would help resolve a kind of annoying wrinkle given the current APIs, but i don't think this is terribly likely to be a need any time soon.

the wrinkle, in more words: we document persistent identifiers (at the end of volumes).

Device numbering is not deterministic and may not match the order in which disks are specified during instance creation. To predictably reference a particular volume at boot time and across reboots, you can use the persistent identifiers provided by the guest operating system (e.g., the symbolic links in /dev/disk/by-id/ on Linux). The device naming convention may change in future releases; such changes will be highlighted in the release notes.

for Linux guests the only stable mechanism to refer to a specific disk is by /dev/disk/by-id/. an /dev/disk/by-id/'s identifier, in turn, includes an NVMe disk's serial number. Windows users won't have as direct a mapping, but the serial number is very much accessible by the guest OS and would be read by your friendly local osquery and related. (IIUC in terms of stable identifiers on Windows, the disk's serial number will let you pick a correct \\.\PHYSICALDRIVE<N> if you wanted such a thing, but my understanding is GPT partition guids are how stable mappings to disk labels are upheld much like fstab on Linuxes)

a guest's setup could include finding /dev/disk/by-id for the root disk and writing scripts that reference that path, expecting it to be persistent. perhaps /dev/disk/by-id refers to a data disk, and "rolling back" is actually rolling back some attached data, unrelated to the boot OS. "restoring" a VM to a prior state may look to user infrastructure monitoring as if all disks got swapped out with new ones!

if replacing a disk's contents with a snapshot would be simple enough, great! we can add to the persistent identifier docs and talk about how to keep disk identifiers persistent. if it turns out this is complicated and not very desirable, then i should go add notes to some docs :)

@iximeow iximeow added the storage Related to storage. label Nov 23, 2024
@iximeow
Copy link
Member Author

iximeow commented Nov 25, 2024

brought this up at the storage huddle and @jmpesp had a rough idea of how we'd do this: if a disk's serial number were distinct from its ID (or ... or name), this could be done by creating a new disk from a "restored to"-d snapshot which would have the same serial number as the previous version of a disk.

we'd want to be careful to ensure that we can't have two different disks with the same serial number floating around - creating a new disk from a snapshot should have a new serial number, but restoring a disk in-place to an old snapshot should preserve serial numbers.

if we have a new disk with a different serial number we'd need to further ensure that snapshots of that new disk also restore to the same serial number.

this all probably gets more straightforward to manage if/when we decouple a disk's serial number from its name or ID. changes around oxidecomputer/propolis#816 will help with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
storage Related to storage.
Projects
None yet
Development

No branches or pull requests

1 participant