Re: [virt-tools-list] RFC: virt-manager feature removals
Hi, I'm sorry for a late response, had an unusually busy summer month... On 2019-07-02 16:58, Cole Robinson wrote: > On 7/2/19 12:19 AM, Povilas Kanapickas wrote: >> Hi all, >> >> On 2019-06-22 02:14, Cole Robinson wrote: >>> On 6/19/19 6:34 PM, Cole Robinson wrote: >>> <...> >>> >>> * 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 >> >> I would like to voice a use case for which scaling is important: when >> the guest and the host have completely different ideas of what the dpi >> is. I personally used "always" scaling frequently when to a low-dpi VM >> from a high-dpi laptop. The "never" scaling option is useful whenever >> the resolution is not very high as some users may want crisp fonts. >> > > Have you experienced the behavior in that bug? No, but I'm using Kubuntu, so maybe that's a bug in Gnome, and maybe only certain versions of it. > For the scaling always case, you are using it to scale down a VM? Both. It always worked. I've used virt-manager since v2.0.0. > Have you used the spice autoresize behavior? This is the default with > virt-viewer if using spice graphics with spice agent installed in the VM. Yes, it worked fine in cases when the spice agent is available on the VM. Unfortunately it's not always possible to install it, e.g. when the guest is MacOS for which libvirt works great. Additionally, sometimes I want to keep the guest resolution different than the host. E.g. in one case I kept having a VM with a small resolution and scaled it up with libvirt because a certain application didn't work well at high dpi. > Have you used virt-viewer much? Does it suit those usecases at all? I didn't use virt-viewer because it's not integrated with virt-manager and thus is inconvenient to use. It's not possible to modify VM details from virt-manager and it needs to be started separately from virt-manager. > FWIW if I dropped this behavior, scaling=never would effectively be the > default so it would cover that usage. That would break many of my workflows completely. Sometimes it's just not convenient or possible to adjust display resolution on the guest side. I guess I would need to keep the functionality in my small fork of virt-manager if this removal went through in the end. It's a pity if virt-manager got dumbed down, as there's no other GUI for libvirt with advanced functionality and a large part of users who use advanced functionality don't want to become experts in libvirt command line, they just want their VMs to work in their use cases. >>> * 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 >> It's unfortunate that people don't know about discard mode and detect >> zeroes options. It's the only way I know that allows reducing qemu disk >> image sizes to what is offered by e.g. Virtualbox. Unfortunately qemu >> still does a bad job in optimizing zeroed-out disk space, but at least >> it will be possible to reap the benefits as soon as the bugs are fixed. >> > > Do you have links to bug reports about those? I'm curious I haven't filed them, it was just my observation that with VirtualBox I was able to make both base and differential images multiple times smaller than what is possible with qemu. Current qemu disk usage is less than the disk usage when the discard mode and detect zeroes options are off, but still not optimal. > I think I will leave these options in for now. I have it on my todo to > start a thread with qemu devs about possibly using discard and/or detect > zeroes by default which will help better understand the pros and cons. Thank you! Regards, Povilas ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] RFC: virt-manager feature removals
On 7/2/19 12:19 AM, Povilas Kanapickas wrote: > Hi all, > > On 2019-06-22 02:14, Cole Robinson wrote: >> On 6/19/19 6:34 PM, Cole Robinson wrote: >> <...> >> >> * 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 > > I would like to voice a use case for which scaling is important: when > the guest and the host have completely different ideas of what the dpi > is. I personally used "always" scaling frequently when to a low-dpi VM > from a high-dpi laptop. The "never" scaling option is useful whenever > the resolution is not very high as some users may want crisp fonts. > Have you experienced the behavior in that bug? For the scaling always case, you are using it to scale down a VM? Have you used the spice autoresize behavior? This is the default with virt-viewer if using spice graphics with spice agent installed in the VM. Have you used virt-viewer much? Does it suit those usecases at all? FWIW if I dropped this behavior, scaling=never would effectively be the default so it would cover that usage. > Unrelatedly, is there any usage data collected from within virt-manager? > In my experience it's very hard to correctly guess how popular a feature > is, so this feature could eventually be really useful to decide what > features to keep and what to drop. > No there is no such usage tracking. Realistically I don't think it will ever be implemented >> * 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 > It's unfortunate that people don't know about discard mode and detect > zeroes options. It's the only way I know that allows reducing qemu disk > image sizes to what is offered by e.g. Virtualbox. Unfortunately qemu > still does a bad job in optimizing zeroed-out disk space, but at least > it will be possible to reap the benefits as soon as the bugs are fixed. > Do you have links to bug reports about those? I'm curious I think I will leave these options in for now. I have it on my todo to start a thread with qemu devs about possibly using discard and/or detect zeroes by default which will help better understand the pros and cons. - Cole ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] RFC: virt-manager feature removals
Hi all, On 2019-06-22 02:14, Cole Robinson wrote: > On 6/19/19 6:34 PM, Cole Robinson wrote: > <...> > > * 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 I would like to voice a use case for which scaling is important: when the guest and the host have completely different ideas of what the dpi is. I personally used "always" scaling frequently when to a low-dpi VM from a high-dpi laptop. The "never" scaling option is useful whenever the resolution is not very high as some users may want crisp fonts. Unrelatedly, is there any usage data collected from within virt-manager? In my experience it's very hard to correctly guess how popular a feature is, so this feature could eventually be really useful to decide what features to keep and what to drop. > * 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 It's unfortunate that people don't know about discard mode and detect zeroes options. It's the only way I know that allows reducing qemu disk image sizes to what is offered by e.g. Virtualbox. Unfortunately qemu still does a bad job in optimizing zeroed-out disk space, but at least it will be possible to reap the benefits as soon as the bugs are fixed. Regards, Povilas ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] RFC: virt-manager feature removals
On 6/22/19 3:20 AM, Peter Crowther wrote: > We use the migration facilities in virt-manager extensively. > Interesting, I would have guessed it didn't get much usage. I guess that means it must work ? :) I'll leave it as is, it's not needed much maintenance effort over the years Thanks, Cole ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] RFC: virt-manager feature removals
On 6/24/19 5:09 AM, Daniel P. Berrangé wrote: > On Fri, Jun 21, 2019 at 07:14:56PM -0400, Cole Robinson 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. > >> * 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 > > I'm not really convinced by this, as I think it dumbs down virt-manager > too much. Telling GUI users to use virsh instead is not a very compelling > story IMHO. virt-manager has multi-host as a feature, and so I think it > is reasonable to expect it to support migration. It isn't only large > openstack scale deployments that can find it useful. > Okay. Given you and Peter's rejection I'm fine with keeping it, it's fairly low maintenance anyways. > >> * 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 > > The right answer is different for VNC vs SPICE. > > For VNC you just want to resize the main window to fit, if possible, > otherwise scale it down. No compelling reason to want to be scaling up. > > For SPICE though if the guest agent is present then you want to guest > display to auto-resize to match whatever the host window allows to > display. That way you never need scaling down. > Okay. If I ever make time to give a bigger rethink how we handle console resizing by default, I will make a thread >> * 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 > > Yes, there's no compelling reason to set the keymap - even non-gtk-vnc > based clients like tigervnc support the scancode mode now. That's good to hear Thanks, Cole ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] RFC: virt-manager feature removals
On Fri, Jun 21, 2019 at 07:14:56PM -0400, Cole Robinson 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. > * 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 I'm not really convinced by this, as I think it dumbs down virt-manager too much. Telling GUI users to use virsh instead is not a very compelling story IMHO. virt-manager has multi-host as a feature, and so I think it is reasonable to expect it to support migration. It isn't only large openstack scale deployments that can find it useful. > * 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 The right answer is different for VNC vs SPICE. For VNC you just want to resize the main window to fit, if possible, otherwise scale it down. No compelling reason to want to be scaling up. For SPICE though if the guest agent is present then you want to guest display to auto-resize to match whatever the host window allows to display. That way you never need scaling down. > * 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 Yes, there's no compelling reason to set the keymap - even non-gtk-vnc based clients like tigervnc support the scancode mode now. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] RFC: virt-manager feature removals
We use the migration facilities in virt-manager extensively. Peter On Sat, 22 Jun 2019, 00:16 Cole Robinson, 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 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 > 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
[virt-tools-list] RFC: virt-manager feature removals
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 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 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
