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

[Povilas Kanapickas]

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