[virt-tools-list] RFC: virt-manager UI philosophy draft

[Cole Robinson]

Hi all,

I've drafted a wiki page about virt-manager UI philosophy, for lack of a
better term, suggestions welcome. The intention here is to provide some
guidance about what types of things we want to expose in the UI, both to
devs, potential contributors, and users requesting RFEs.

https://github.com/virt-manager/virt-manager/wiki/WIP-UI-philosophy

I don't think there's much new here, it's just formalized. There's a
section at the end of the wiki page for previously rejected features as
well. If people are cool with this document I'll use it to close a bunch
of upstream bugs as well which will grow that list.

Another part of my plan for this is to apply the standards to the
current UI which would result in feature removals. I'll put my thoughts
in a follow up mail.


##  virt-manager UI philosophy

virt-manager is a UI toolbox-style frontend for libvirt. It provides UI
access to common virt management tasks and operations. virt-manager aims
to provide a simple UI, but not too simple that it excludes valid
usecases. virt-manager prioritizes stability over features.

* _Basic virt users_ should be able to meet their needs with virt-manager.
* _Intermediate virt users_ should generally find virt-manager
sufficiently flexible for their needs.
* _Advanced virt users_ will not find explicit UI support for their
advanced use cases, but virt-manager should still function correctly in
the face of their manually configured advanced virt usage. virt-manager
should not get in their way.

See the user definitions at the end of this doc for more details on those.

Here are some things that virt-manager explicitly is not aiming to
reimplement:
* gnome-boxes: a heavily desktop integrated VM manager with an emphasis
on UI design and simplifying virt management. They prioritize a seamless
designed experience over flexibility, our goals are different.
* virt-viewer/remote-viewer, vncviewer: our graphical VM window should
'just work' for most needs but any advanced console configuration is
left up to these other better suited tools.
* VirtualBox, VMWare Workstation: It's a nice idea to aim to be the
equivalent of those apps for the QEMU+KVM+Libvirt stack. But to get
there would require a level of resource investment that is unlikely to
ever happen.
* oVirt, Openstack: virt-manager does not aim to support management of
many hosts with many VMs. virt-manager won't reject this case and we try
within reason to keep it working. But the UI is not designed for it and
we will not change the UI to facilitate these style of usecases.


## How do we evaluate UI changes

When is it worth it to expose something in the UI? Here's some criteria
we will use:
* How many users do we expect will use it: This is handwavy of course
but some things come up in email/IRC discussion regularly, and some are
mentioned once in 5 years.
* How critical is it for users who need/want it: if it's an absolute
blocker just to get a working config for some people, that can influence
the discussion
* How self explanatory is the feature: 'Enable 3D acceleration' is
fairly self explanatory. Disk io native vs threads, not so much.
* How dangerous or difficult to use is the feature: If it works in only
specific cases or renders the VM unbootable for certain scenarios, this
matters.
* How much work is it to maintain, test
* How much work is it to implement: If something requires significant
app specific logic on top of libvirt, libosinfo, or spice-gtk that would
also be useful to other virt apps, it is suspect. We should be aiming to
share common functionality


## User definitions

### Basic virt user
They know little or nothing about libvirt, qemu, and kvm, but they
understand the high level concept of a virtual machine. They have a
Windows or Linux distro ISO and they want to create a VM and interact
with it graphically. They should be able to figure out how to do that by
running virt-manager and following the UI. The defaults we provide for
new VMs should be sufficient for their needs.

After the VM is installed, the UI should facilitate intuitive UI tasks like:

* lifecycle operations: start/stop/pause the VM; save, snapshot the VM;
delete, clone the VM
* rename the VM; change the VM title or description
* eject/insert CDROM media; change VM boot order
* increase VM memory
* attach a host USB device to the VM; possibly add an additional disk to
the VM
* graphical operations like send a keycombo, screenshot

### Intermediate virt user

They know more about virt in general but we do not assume they have ever
edited libvirt XML or run the qemu command line. They are a more
intermediate tech user anyways. They may know about less standard virt
features and they want to enable them for their VMs. Or they are using
VMs as part of a specific workflow, possibly for a development
environment, or hosting personal services on their own network, or
managing VMs on a remote host. This is the fuzzy area. We want to
support these people but each request needs to be handled on a case by
case basis.

Here's some of the things the current UI supports that fit this bucket:
* Management of remote virt hosts
* Management of non-qemu/kvm libvirt drivers: lxc, vz, xen, bhyve
* Support for non-x86 VM creation: aarch64, armv7l, ppc64, s390x
* Change VM CPU model or mode
* UEFI config for new VMs
* VM direct kernel/initrd boot
* VM serial console access
* VM use of network bridge or macvtap
* Spice/virgl 3D acceleration usage
* Libvirt storage pool management
* Libvirt virtual network management
* Ideally every VM UI edit operation should be justifiable in this context

### Advanced virt user

They have some experience with libvirt XML or qemu command line. They
know that they need some advanced XML knob for the domain or their
device. We want virt-manager to still be useful to these users for
fullfilling advanced and intermediate needs, but not get in the way or
prevent usage of their advanced config. Some examples:
* Anyone managing many hosts and many VMs
* Anyone needing nearly all performance tuning configuration
* Generally anybody that knows the qemu command line or XML config
options they want
* Generally any use case that requires special host or guest
configuration outside virt-manager