Tracking: local disks UI

[david-crespo]

From 11/10/2025 storage huddle:

• Naming: new disk type = "local"
  • avoid the mention of "ephemeral" because it's designed to persist (see bullet below)
  • consider renaming the crucible-backed disk to type = "replicated" "distributed".
• Data persistence: Local disks are kept around and remain intact by default. They go away only when explicitly deleted by the user.

Other notes:

• Number of disks: Hypervisor team is working to expand the max number of slots to 12 (1 for initial boot disk which must be a crucible volume, 1 reserved for cloud-init, up to 10 to use all the physical disks available in a sled). In other words:
  • New VM: Besides the boot disk, user can specify up to 10 local + distributed disks.
  • Existing VM: User can attach it to max 11 disks of any combination, and designate any disk as the boot disk (in case user has made a local disk bootable afterwards)
• Max disk size: Still TBD, SN861's raw disk space is 6.4 TB which is ~5.8 TiB. We'll see what comes out of the inventory table but we may want a client-side validation (similar to max vcpu/memory).
• Snapshot: This is out of scope in r18. Local disk is not allowed for snapshot creation initially.
• Other implied processing logic and UX:
  • When creating a VM, user cannot create/attach to local disks only. The boot disk has to be a crucible volume.
  • User can see the disk type (virtual disks vs local disks) via some new attribute added to disk metadata.
  • Local disks cannot be set as the boot disk in an existing VM. (dropped based on feedback)
  • All disks attached to a VM are detached when deleting a VM.
  • User can create a local disk on its own (i.e. outside the context of create VM). The only parameter to specify is disk size.
  • Local disks located in different sleds cannot be attached to the same VM.
  • We'll probably punt on the option of auto-deleting local disks as part of a VM delete operation. If we decide to implement this, it won't be the default setting (at least in the beginning, until we have more customer feedback) and the same design can be applied to distributed disks as well.

Sub-issues to be added.

https://rfd.shared.oxide.computer/rfd/0584
https://rfd.shared.oxide.computer/rfd/0590

[askfongjojo]

@jmpesp @leftwo - I added a set of UI/UX related processing logic to the ticket description. Do they sound about right to you? Please make edits as you see fit.

@david-crespo @benjaminleonard @charliepark - Please see if there are other open questions to address before we can proceed with the UI design.

We still need to work on the design around presenting storage capacity to the operator and silo administrators. I'll follow up on this aspect next.

[jmpesp]

At first glace this all looks good. some thoughts:

• snapshots are definitely not happening for 18, there's no maybe about it haha
• users won't be able to attach 12 disks because they don't currently control the cloud init volume at all, so the limit they see is 11.
• we may be able to get the max possible disk size from inventory?
• for deletion, the original implementation won't have any different behaviour than for a crucible backed disk, namely that they are not deleted unless explicitly deleted by the user. whatever behaviour we change here will probably apply to both disk types
• in the sled agent code, we're not limiting the type of boot disk a vm can have. I was imagining the use case of booting from something, installing an OS onto a local disk, then stopping the instance, detaching the original boot something, then booting from the OS (which is on a local disk).

[david-crespo]

Fortunately I see very little console work here. We just have to add a radio for local vs. replicated disks everywhere you can create a disk:

• Instance create
• Direct disk create
• Disk create on instance detail

and display the disk type everywhere you can view disks:

• Top level project disk list
• Instance storage tab (both create and attach)
  • Disable set as boot disk for local disks
• Attach existing disk on instance create

The more interesting part is thinking about how much to say to explain the difference, and how to make it clear that you almost certainly want replicated disks unless you know for sure you don't.

[askfongjojo]

Changed the naming of crucible disks from "replicated" to "distributed" based on the most recent discussions.

[askfongjojo]

We still need to work on the design around presenting storage capacity to the operator and silo administrators. I'll follow up on this aspect next.

I put the above on hold when we were talking about a whole different implementation (specifically, pre-allocating local disk capacity at RSS time). Now that it's no longer necessary, I've pushed the RFD I started working on two weeks ago. RFD 624 covers several proposed changes. It's in prediscussion state at this time as I'd like to get some feedback from @benjaminleonard first because a lot of what's involved is UX.

[benjaminleonard]

@askfongjojo we could schedule a little chat, or it might be easier to move it to discussion and I can comment inline?

And I agree with @david-crespo 's note on the proposed console changes. I think we'll want to emphasise consequences at the point of disk creation, and in other cases we can lean more on more subtle tooltips / external docs links.

Do you think it's possible we might add more disk types in the future also? Since that might impact our approach.