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

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 issue does not name implementation files, tests, or a specific entry point. Start by locating the snapshot and disk APIs, then determine whether replacing disk contents while retaining the serial number is supported; done would mean an agreed API behavior or documented alternative for preserving disk identifiers.