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

[Cole Robinson]

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