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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
