Fix the "overview" card information classification

[garrett]

As seen in #969 (and before): The overview card is a monstrosity. It has grown organically and everything inside has been tossed in, mainly under "general". There's also "hypervisor details", which doesn't seem to be a useful group either, as these are all "details" of some sort (even under "general") and it's not clear what is what or how anything relates to each other.

[garrett]

Here's a screengrab from #969 to show what I'm talking about:

We need to classify and organize this information.

For a start, I see at least the following types of information:

• type (system)
• state (state)
• system attributes (memory, vCPUs & type, hypervisor details)
• boot order
• configuration options (autostart, boot order)
• integration (vsock identifier perhaps?, watchdog)

Is this right? Is there a better way to group these?

Should we split this out to multiple cards?

@skobyda: WDYT? ("What do you think?")

[subhoghoshX]

We can probably look into existing tools like VirtualBox, Virt Manager etc.

From VirtualBox:

Here System has Memory & Boot order. We can probably also put vCPUs and CPU type in there.

System:

1. Memory
2. Boot order
3. vCPUs
4. CPU type

Hypervisor details section from Virt Manager:

The current Hypervisor details sections seems okay.

Once you've reached a definite conclusion. I'd like to work on it, if it's okay :)

[garrett]

Thanks for sharing how VirtualBox does it!

@skobyda and I talked about this in a call just a few minutes ago and we have some ideas.

We worked further on the grouping in a shared document.

I think we might want to shift the layout around to go from left to right, then top to bottom instead of being top to bottom, left to right (as it is right now).

• Think about moving connection and state to the top header?
• First section: Instance info (or "Flavor" or some other terminology) at the top with Memory, vCPUs and CPU type, and perhaps emulated machine which spans across the top.
• Second section: Boot-related items
• Third: Additional configuration (watchdog)

However, there's also autostart, which is kind of the odd one out. It's kind of booting, but it's really tied to the VM itself (where it autostarts based on the host machine, not the boot process inside the VM on the guest).

We're not done with this, but I have some ideas on how to start laying it out (kind of written above). I'll have to work it through a layout tool (probably Penpot, but perhaps Excalidraw or Inkscape).

I've added the needsdesign label to help find this again next week.

[skobyda]

Hey, I think in close future GPU configuration also might get implemented in the overview card: #554
Let's account for that in the new design

Edit: On second thought, since there can be multiple video devices attached to a VM, then when GPU gets implemented, it will probably have its separate card among other devices such as disks, and network interfaces... So then I guess we don't have to account for GPU in this card.

[skobyda]

Hey, I think in close future GPU configuration also might get implemented in the overview card: #554 Let's account for that in the new design

[skobyda]

Closing in favor of #1027