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 :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
