We use the migration facilities in virt-manager extensively. Peter
On Sat, 22 Jun 2019, 00:16 Cole Robinson, <[email protected]> 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 > [email protected] > https://www.redhat.com/mailman/listinfo/virt-tools-list >
_______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
