[virt-tools-list] RFC: virt-manager feature removals

[Cole Robinson]

On 6/19/19 6:34 PM, 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

Following on from the UI philosophy document, here's a list of features
in current virt-manager/virt-install features that I think are
candidates for removal.

* virt-convert: This is not strictly about the philosophy document but
I'll mention it now: virt-convert takes an ovf/ova or vmx file and spits
out libvirt XML. It started as a code drop a long time ago that could
translate back and forth between vmx, ovf, and virt-image, a long dead
appliance format. In 2014 I converted it to do vmx -> libvirt and ovf ->
libvirt which was a CLI breaking change, but I never heard a peep of a
complaint. It doesn't seem to do a particularly thorough job at its
intended goal, I've seen 2-3 bug reports in the past 5 years and
generally it doesn't seem to have any users. Let's kill it. If anyone
has the desire to keep it alive it could live as a separate project
that's a wrapper around virt-install but there's no compelling reason to
keep it in virt-manager.git IMO

* the migration wizard: migration is IMO an advanced use case. It
requires host config outside of virt-manager to have a chance of
working. the only place migration is really critical for users is
serious multihost production scenarios where virt-manager isn't really
appropriate per the UI philosophy. And besides some UI friendliness
virt-manager doesn't really add much over virsh IMO. Nearly every bug I
can recall about its usage was from one person who happens to be a
co-worker developing qemu migration, and redhat QE, which means it's
either perfect or no one uses it :) I think it should go

* virInterface listing entirely. v2.0.0 removed the UI for the
virInterface management. We still ask libvirt for a list of interfaces
to mainly populate domain <interface> source selection: for listing
bridges, and for listing all host interfaces as macvtap targets. This
is still an arguably useful thing to have. However there's some issues
with the current implementation of this UI:
  * Our macvtap filtering is poor: we exclude some valid devices like
    bonds, but include invalid devices like wlan which don't work
    with macvtap
  * macvtap is kinda problematic in general because it doesn't provide
    out of the box host<->guest communication, and it requires a
    special XML option just to get working ipv6. Users that know they
    want it usually know this distinction, but if someone chooses it
    without understanding the implications it can cause confusion.
    This puts it hovering the intermediate/advanced user line which
    makes me want to not advertise it as prominently as we currently do,
    with an explicit list of host interfaces
  * The default source selection is not flexible enough. If the user
    has a non-empty bridge on their host virt-manager will always use
    it as the default. virt-install is different: if a bridge
    devices is the default route it will use that, otherwise it
    uses network=default

Ideally what I would change it to: drop interface listing. Make the
drop down have 'Specify bridge device...' and 'Specify macvtap
device...' which the user has to manually type their device into to use
it. Change the default choice to match virt-install but with one key
difference: if net=default does not appear to be the libvirt standard
'default' net (so, NAT with an IP of 192.168.12X), then we always use
'default', otherwise use the current virt-install logic. This gives
users a way to override the virt-manager default. And since <network>
objects can support bridge, macvtap, etc, this should cover any usage
someone wants for default networking. It let's us drop code, simplify
the UI, make the default network choice more predictable and easier to
override. It drops any potential weird behavior differences between
distros due to different interface API backends. It makes it less
tempting for basic/intermediate users from choosing macvtap without
understanding the implications. Downsides are it becomes more work to
select a bridge (in some cases) and macvtap (in all cases). I'm willing
to roll the dice and see what the reaction is.

* all code trying to handle libvirt lacking object events APIs. I
haven't quite done the research on this one but I'm just floating it for
discussion. I believe all hypervisors virt-manager supports have domain
events and have had them for a long time. We still have some code paths
in the app to try and handle the case when object events are not
available, and if so, do regular polling intervals, and calls at various
places in the code to trigger a polling refresh on demand. I think these
old code paths are reasonably robust for the domain objects but still I
think they are possibly never exercised.

Non-domains are different. Event support has been around in libvirt
since 2016 for storage and nodedevs. In the local case it
doesn't matter because no one is realistically running virt-manager
locally against a libvirt instance older than that. Remote case might be
a bit different, someone could be managing a host with older libvirt.
They could still probably get by without the event support, the app just
might not be reactive to newly created objects. The place it might bite
them is trying to create a new VM, the app might not notice the storage
volume it just created. But I'm not sure if we really need to care about
it or not...

The main crux of it is that the non-event code paths are essentially
untested and I don't think it's worth it to explicitly invest time in
adding testing, so I'd rather be explicit and rip it out.

* console scaling options (always, never, fullscreen): we've had this in
the UI forever, but I don't think it has much usage. virt-viewer doesn't
even expose it how we do, instead it just has a zoom option which I
don't think we need to implement either. just today there was a bug
reported saying that scale->always is fairly obviously broken and has
been for a few releases, which makes me think no one is using it.
dropping this could be part of a larger think of how console sizing
works, if we should default to spice auto-resize, or if there's some
more modern config we should be taking care of.
https://bugzilla.redhat.com/show_bug.cgi?id=1722088

* UI maxmem and maxcpu notions, and related memballoon and cpu hotplug
operations. These have been in the UI forever but I'm not sure people
actually use them. cpu hotplug has always been a mess, and unless the
user plans ahead by setting a high maxmem value ballooning is only good
for reducing memory. These all sound like advanced usage to me that
just confuses the typical usecase of adding more mem or vcpus to an
offline VM. And the hotplug operations with virsh are simple to invoke.
So I'd like to drop this from the UI

* graphics keymap stuff. in virtinst/hostkeymap.py we have some logic
to parse host keymap from various locations like /etc/vconsole.conf and
try to map it to a qemu keymap name. You can trigger this via the UI in
the keymap dropdown 'Copy local keymap' and via virt-install --graphics
keymap=local, though the latter isn't even documented. This all was
the default behavior we used and essentially needed years ago, but
qemu and spice-gtk/gtk-vnc have for a decade been able to route
around the need by sending raw scancodes back and forth. This code
could in theory still be valuable for someone to set the keymap to
work with a vncviewer for example which doesn't have the scancode
support IIRC, but I think at that point we can just ask them to specify
the keymap themselves. So I propose killing hostkeymap entirely, making
keymap=local print a cli warning, and drop the keymap dropdown from the
UI. Users can set it in the XML editor if they need it

* graphics spice tlsport UI: configuring spice tls is definitely an
advanced usecase that requires external host config. tlsport is only
interesting in that case. I think the XML editor is sufficient

* network virtualport configuration: this is some really obscure
stuff for configuring VEPA for macvtap devices. I don't think it gets
any usage in practice. I think a smaller subset of this UI is shared
with openswitch config but I believe it's just a single field, we
could keep that even though I don't think many people use it either

* disk: storage format: this was from before the days when we
storage-ified everything and we could get the disk format wrong, telling
qemu it has a raw image when it's qcow2. shouldn't be needed anymore for
normal virt usage

* disk: bus editing: maybe keep this for the customize wizard, but
it should go away for existing disks, changing it for an existing VM is
definitely a 'shoot yourself in the foot' type of thing for most users

* disk: serial: I know this is useful in some cases but seems quite
obscure. I think the XML editor is fine unless there's some common
usecase I'm missing

* disk: performance options: cache setting seems to be common enough
that we should keep it. io threads vs native is rarely changed in
my experience, our default seems good enough, so it's fine to drop.
discard mode and detect zeroes I'm unsure about. they are fairly new
to the UI. discard mode is definitely something people inquire about
setting, I feel like we should have a discussion about whether setting
this by default makes sense. detect zeroes I don't hear much
about but I wonder as well if it's possible to set as a default

* adding parallel devices. in practice I don't think many people even
use it at the qemu level, and if they do the use case is obscure enough
that they can set the XML themselves. also it's disabled in RHEL8.
dropping it from the addhw UI won't actually save us much code though
so I don't have strong feelings about it, but I think in practice it's
just so obscure that no one is going to miss it when it's gone. And I'd
like to make the UI more consistent when it comes to such things


Thanks,
Cole


- Cole