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

[Cole Robinson]

On 6/20/19 9:58 AM, Andrea Bolognani wrote:
> On Wed, 2019-06-19 at 18:34 -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.
> 
> With the caveat that I'm not closely involved with virt-manager
> development, the document seems pretty reasonable to me, and does
> not seem to clash in any major way with the understanding that I
> have gathered by following various design discussions over the
> years, so thumbs up overall!
> 
> I'd like to point out a single item that I might disagree with,
> though:
> 
>> ### Intermediate virt user
>>
>> * Support for non-x86 VM creation: aarch64, armv7l, ppc64, s390x
> 
> I'm obviously biased here, since a big part of what I do is caring
> about non-x86 architectures :) but I would consider any application
> that doesn't have proper multi-architecture support as a core
> principle to be inherently flawed, so having to spell this out at
> all seems backwards.
> 

For most cases like a C library, I agree. But this a bit different
though, apps need to hardcode some knowledge about every non-x86 arch in
order to generate a working config. Things have unified a _lot_ over the
past few years, but there's still the issue that say spice isn't
available on PPC64 hosts, that aarch64 requires UEFI to be able to use
traditional install methods where x86 doesn't, that some archs need an
explicit non-default machine type like 'virt' while others can get away
with the default. If someone wrote a new virt-manager tomorrow I
wouldn't begrudge them ignoring non-x86 until someone with hardware
showed up with patches or offered to help.

> Now if you were talking about the ability to create non-x86 guests
> on x86 through the use of TCG, then I absolutely agree that it's an
> advanced feature mostly interesting to developers. But being able
> to create and managing non-x86 KVM guests on a non-x86 host should
> be as vital to virt-manager as doing the same on x86.
> 

I understand the sentiment. But the general point of this exercise to
rank some kind of priority or importance. My perception is that using
virt-manager for non-x86 is low single digit percent usage of the app,
and that most of those users are highly technical people to begin with,
using virt as part of a development environment and not for desktopy use
cases. And I suspect most of those if they are using it are managing
virt on a remote non-x86 host anyways, which also puts it into
non-beginner territory IMO.

Thanks,
Cole