You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :)
The text was updated successfully, but these errors were encountered:
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.
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).
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 localosquery
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 :)
The text was updated successfully, but these errors were encountered: