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

[Peter Crowther]

We use the migration facilities in virt-manager extensively.

Peter

On Sat, 22 Jun 2019, 00:16 Cole Robinson, <crobinso at redhat.com> wrote:

> 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
>
> _______________________________________________
> 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/20190622/b68b6b45/attachment.htm>