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

[Peter Crowther]

Thanks, Cole - very useful!

I'd like to challenge one aspect, which is your single axis of basic /
intermediate / advanced virt *user* in the definitions at the end.  I
wonder whether you're confounding two axes: user, and also environment.
Many of the exclusions you're choosing to put into the advanced user
section are definitions of the environment: many hosts, many VMs, special
host or guest configuration.  You make that explicit at the top of the
document, but not at the end.  We're by no means "advanced users" in most
senses; we want the simplest thing that could possibly work (which is why
we're not touching OpenStack with a bargepole - too many moving parts).  Is
it worth moving some of the environment stuff into an explicit "advanced
virt environment" section to match the top section?  Makes it easier for
folks like me to reason about the philosophy!

Cheers,

- Peter

On Wed, 19 Jun 2019 at 23:35, Cole Robinson <crobinso at redhat.com> 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
>
> ### 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
>
> _______________________________________________
> virt-tools-list mailing list
> virt-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20190620/69bab752/attachment.htm>