<div dir="auto">We use the migration facilities in virt-manager extensively.<div dir="auto"> </div><div dir="auto">Peter </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 22 Jun 2019, 00:16 Cole Robinson, <<a href="mailto:crobinso@redhat.com">crobinso@redhat.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. > > <a href="https://github.com/virt-manager/virt-manager/wiki/WIP-UI-philosophy" rel="noreferrer noreferrer" target="_blank">https://github.com/virt-manager/virt-manager/wiki/WIP-UI-philosophy</a> 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. <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1722088" rel="noreferrer noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1722088</a> * 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 <a href="mailto:virt-tools-list@redhat.com" target="_blank" rel="noreferrer">virt-tools-list@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/virt-tools-list" rel="noreferrer noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/virt-tools-list</a> </blockquote></div>