No way to tell which is the boot disk

[david-crespo]

In the console we currently rely on the order of disks to mark out the boot disk for an instance. The boot disk is supposed to be the first disk (or at least I thought it was — will try to find relevant discussion). However, the disks come back in alphabetical order, which makes our UI wrong.

We are explicitly sorting instance disks by name.

omicron/nexus/src/db/datastore.rs

Line 1689 in 9ec389f

paginated(dsl::disk, dsl::name, &pagparams)

I didn't call this issue "the order is wrong" because ultimately that's not a very good API for this and I would rather have a more reliable property on the response. Maybe this should be stored as part of the disk state: in addition to the ID of the instance it's a attached to, a boolean indicating whether it is the boot disk.

I don't have a strong opinion on how important it is to say which disk is the boot disk — if it's not that important, it would be a lot easier not to bother making the distinction in the UI than it would be to make the necessary API changes to reliably make said distinction.

[davepacheco]

Even if we add a property like that, I think there is an actual ordering to the disks (reflecting the order presented to the OS) and we may want the API to list them in that order (and maybe let you change it?)

[jclulow]

The order may well be sparsely populated too; e.g., if you add three disks and then detach the middle one, I think we'd have a hole. @pfmooney?

[pfmooney]

Yeah. Given how OSes can be grumpy about disks moving around, I think it would need to be sparse.

[jmpesp]

@david-crespo what's the InstanceCreate body for the animated gif repro?

[david-crespo]

@jmpesp it looks like this. Since disk create during instance create isn't implemented, we create the boot disk first with a separate POST, so all disks are considered attachments. I assume being first here is what makes boot-disk the boot disk?

{
  "name": "abc",
  "hostname": "abc",
  "description": "An instance in project: mock-project",
  "memory": 4294967296,
  "ncpus": 2,
  "disks": [
    { "type": "attach", "name": "boot-disk" },
    { "type": "attach", "name": "disk-3" }
  ]
}

[jmpesp]

I assume being first here is what makes boot-disk the boot disk?

Correct, yeah.

[askfongjojo]

This will be confusing for console users. Perhaps change the UI to show just a list of disks attached rather than showing something potentially incorrect? (I thought instance create did something wrong when I saw the data volume got listed as the boot disk of a 2-disk test VM I made.)

[david-crespo]

I think we can get the API to tell us which is the boot disk somehow, whether through a property (maybe even on the instance response — boot_disk_id) or through the order of the list.

[leftwo]

Knowing the actual boot disk, vs. the first disk presented to the OS may not be something we can determine.
If the first disk we present to the OS is not bootable, but the 2nd disk is, I believe (and ignore me here if this is wrong)
the OS will boot from the 2nd disk. This could result in confusion on the users side as we told them disk "A" was their
boot disk, but the OS booted from disk "B".

[david-crespo]

When that happens, can Propolis not tell Nexus which disk was the one that booted, like as part of the instance state?

[jclulow]

It's complicated. If there is a possibility that the firmware will boot a disk other than the one in the first slot, the EFI firmware in the guest would need to communicate that out to the hypervisor somehow. I don't believe it does anything like that today.

[david-crespo]

In that case then yeah, Angela is clearly right that being wrong is worse than saying nothing. Users can use names to differentiate for themselves, and later tags. Also the order should be a reasonable hint most of the time.

The change to be made is a trivial one in the console — put the disks in one list and don’t say anything about boot vs. other. Nothing for API to do until we want to figure out how to actually indicate the boot disk, which may not be any time in the foreseeable future.

[askfongjojo]

We can probably assume users will name their disks with something meaningful (instead of disk1, disk2, disk3). E.g.

It'll be fine to just list all the disks attached and user will likely know which one is which. (the image also explains why I was rather surprised!)