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

Mon Jun 24 09:15:16 UTC 2019

On Wed, Jun 19, 2019 at 06:34:38PM -0400, Cole Robinson wrote:
> 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

I would note that this is essentially the use case / scenario that
GNOME Boxes aims to fill.

Boxes will inevitably do a better job here since its simplified
view will enable it to be more friendly than virt-manager will
be able to do.

IMHO virt-manager should position itself as the natural choice of
tool for someone who wants a desktop app, but has outgrown what
GNOME Boxes can offer them.

Thus I think virt-manager should be primarily focusing in its aims
towards the Intermediate virt user, with a bias towards the advanced
side of things.

> ### 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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|