On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote: On 11/12/20 11:03, Stephen Finucane wrote:
Design discussion for interested parties. As discussed during the nova team meeting today, we're looking at providing support for virtio- based input devices in nova, given benefits w.r.t. performance and security (no emulated USB bus!). The current proposal I have for this is to introduce a new image metadata property, 'hw_input_bus', and extend the existing 'hw_pointer_model' image metadata property, which currently only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' values. This means you'd end up with a matrix something like so:
+------------------+--------------+------------------------+ | hw_pointer_model | hw_input_bus | Result | +------------------|--------------+------------------------+ | - | - | PS2-based mouse [*] | | usbtablet | - | USB-based tablet | | usbtablet | usb | USB-based tablet | | usbtablet | virtio | **ERROR** | | mouse | - | USB-based mouse | | mouse | usb | USB-based mouse | | mouse | virtio | virtio-based mouse | | tablet | - | USB-based tablet | | tablet | usb | USB-based tablet | | tablet | virtio | virtio-based tablet | +------------------+--------------+------------------------+
[*] libvirt adds these by default on x86 hosts
dansmith noted that the only reason to select the 'mouse' pointer model nowadays is for compatibility, and something like a virtio-based mouse didn't really make sense. That being the case, I agree that this change is likely more complex that it needs to be.
+1, agree that having several user choices for pointer + bus that result in invalid or nonsensical combinations would not be a positive UX.
We do, however, disagree on the remedy. dansmith's idea is to drop the 'hw_input_bus' image metadata property entirely and simply add a new 'virtiotablet' value to 'hw_pointer_model' instead. This still leaves the question of what bus we should use for keyboards, and his suggestion there is to extrapolate out and use virtio for keyboards if 'hw_pointer_model=virtiotablet' is specified and presumably USB if 'hw_pointer_model=usbtablet'.
Needless to say, I don't like this idea and prefer we took another tack and kept 'hw_input_bus' but didn't build on 'hw_pointer_model' and instead "deprecated" it. We can't really ever remove the an image metadata property, since that would be a breaking upgrade, which means we'll eventually be left with effectively dead code to maintain forever. However, I don't think that's a big deal. 'hw_pointer_model=usbtablet' is already on a path to obsolescence as the Q35 machine type slowly becomes the default on x86 hosts and the use of non-x86 hosts grows since neither support PS2 and must use a USB-based input device. In addition, I think the extrapolation of 'virtiotablet' to mean also virtio-based keyboard is unclear and leaves a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64 hosts (where it's currently added by default), since we don't currently do this extrapolation and introducing it would be breaking change on x86 hosts (instances would suddenly switch from PS2-based keyboards to USB-based ones).
If I understand correctly, we do choose the "best fit" keyboard based on architecture, independent of the requested hw_pointer_model, today. Not quite. libvirt on x86 will automatically add a PS2 mouse and keyboard (even if you request something else) because that's what QEMU does. On all other platforms (to the best of my knowledge, based on Kashyap quizzing a handful of multi-arch libvirt devs), this must be done manually. We currently only do this for AArch64, through the non- configurable addition of a USB keyboard [1]. There is currently no way to request e.g. a USB or virtio keyboard on any architecture. [1] https://github.com/openstack/nova/commit/b92e3bc95fd It feels like it would be simpler to continue doing that and add a virtio choice to hw_pointer_model and let the driver pick the "best" keyboard to go along with that. Is it your view that having the
driver choose a virtio keyboard if hw_pointer_model=virtiotablet is inconsistent with the existing "best fit" keyboard selection behavior?
My concerns are twofold. Firstly, having the value of 'hw_pointer_model' influence the keyboard bus is poor UX, since this "feature" is not at all apparent from the property name. Secondly, 'hw_pointer_model' is a poorly designed property, given it configured the bus as well as the model, munging the two. To be clear, I agree that having different buses for keyboard and pointer makes no sense. There's no reason they shouldn't be the same. I'm just saying that configuring the bus for input devices via an appropriately named 'hw_input_bus' image metadata property makes much more sense that maybe getting one configured magically based on the "pointer model" in use.
From what I understand, the pointer is the only user selection we can guarantee and the keyboard is architecture dependent.
Again, not really. There isn't an analog for pointer vs. mouse when it comes to keyboards. The keyboard isn't architecture dependent. What is architecture dependent is whether you get a keyboard and mouse by default (yes on x86, in the form of a PS2 mouse and keyboard, and no for everyone else).
If we "deprecated" hw_pointer_model and introduced hw_input_bus, how does the user know which thing (pointer or keyboard) they are specifying? If users can't actually choose the keyboard and can only choose the pointer, wouldn't presenting a selection of a generic "hw_input_bus" be more confusing than hw_pointer_model?
They can choose the _bus_ that the keyboard uses. There's an assumption here that if you request a graphics device (VNC, SPICE, ...) then you will get a keyboard and tablet input devices, because that graphics device is unusable otherwise. There is also an assumption (based on dansmith's comments about mouse being only used for legacy compat reasons) that the user will never want to explicitly request a 'mouse' pointer model and should therefore get 'tablet' by default. Based on these two assumptions, the only thing remaining is to decide how the keyboard and tablet devices will be attached to the guest...achieved via a sensibly named 'hw_input_bus' image metadata property. That seems reasonable to me. Stephen Best, -melanie
We need to decide what approach to go for before I rework this. If anyone has input, particularly operators that think they'd use this feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶ ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel free to either reply here or on the review [1].
Cheers, Stephen