[nova] How best to provide virtio-based input devices?

melanie witt melwittt at gmail.com
Fri Nov 20 21:46:35 UTC 2020


On 11/20/20 10:14, Stephen Finucane wrote:
> On Wed, 2020-11-18 at 16:12 -0800, melanie witt wrote:
>> On 11/16/20 02:41, Stephen Finucane wrote:
>>> On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote:
>> OK, so the introduction of virtio would be the first time that we would
>> be able to set all of tablet, mouse, and keyboard to the same bus. What
>> if they don't want all three input devices, could it cause any
>> undesirable behavior for them?
> 
> You don't have any choice: if you have a graphical console, you need a 
> pointer (mouse or tablet) and you need a keyboard for it to be usable. 
> Conversely, if you don't have a graphical console, then we've no need to 
> add either. If a user didn't want a mouse and keyboard then they can and 
> should disable graphical consoles.

Ack, understood.

>> And then if they set hw_input_bus=usb for libvirt on x86 they'd get a
>> USB tablet, a PS2 mouse, and a PS2 keyboard and on AArch64 they'd get a
>> USB tablet, ? mouse, and USB keyboard.
> 
> No, on x86 you'd get a USB tablet and keyboard, and a PS2 mouse PS2 
> keyboard. This is because there isn't currently a way to disable the PS2 
> devices in libvirt/QEMU. However, this is not an issue since the guest 
> OS will default to using the USB-based devices (or so danpb tells me). 
> Also note that this is very similar to how things currently work with 
> 'hw_pointer_model=usbtablet': setting this means you'll get a USB tablet 
> (but not keyboard), and a PS2 mouse and keyboard.
> 
> On AArch64 and any other non-x86 host, they'd get simply a USB tablet 
> and a USB keyboard because libvirt doesn't have that QEMU quirk to work 
> with.

OK, this was something I didn't previously get. So, your proposal is 
that if you were to add hw_input_bus=usb you would also add the USB 
keyboard and USB mouse for x86. So you end up with USB tablet and 
keyboard and mouse on x86. You just also happen to have PS2 keyboard and 
mouse as well and they will not be defaulted.

And then AArch64 would get USB tablet and keyboard and mouse with 
hw_input_bus=usb.

I had been previously thinking the hw_input_bus addition would be a 
change in name only and not a change (additive change) of behavior as well.

>> I'm sorry I'm not seeing how hw_pointer_model=virtio isn't the clearest,
>> least confusing way to add virtio. (Or maybe
>> hw_pointer_model=virtiotabletmousekeyboard ?!)
>>
>> Thanks for taking the time to explain the technical details around this
>> area of the code. I think I now understand your point of view since the
>> name of hw_pointer_model doesn't nicely convey the tablet+mouse+keyboard
>> setting when it comes to virtio. On the flip side of that, I feel like
>> hw_input_bus=usb when it's only going to be honored for the tablet for
>> libvirt on x86 seems even less nice.
> 
> Given the above, do you still have the same concerns around using 
> hw_input_bus?

Now that I understand that the user's bus choice via hw_input_bus would 
indeed be honored for all of tablet, keyboard, and mouse for all 
architectures, I can acknowledge that hw_input_bus could be an improved 
name over hw_pointer_model. I still think the main, important user 
selectable bit is the pointer, so I don't think the hw_pointer_model 
name is so terrible.

The remaining concern would be around the work users and operators would 
have to do to adopt the new name. Are you thinking that existing images 
just stay as-is and if users want virtio or all USB they can only get it 
via hw_input_bus=virtio or hw_input_bus=usb and that will facilitate use 
of the new image property?

So the summary would be:

* hw_pointer_model=usbtablet you still get a USB tablet and the rest is 
unselectable

* hw_input_bus=usb you get USB everything

* hw_input_bus=virtio you get virtio everything

If this is the case, then I would say I'm no longer actively opposed to 
adding hw_input_bus image property to get virtio, but I'm still not sure 
whether it's worth the amount of change and new image property users 
need to learn, given that pointer is the main thing users care about and 
we already have the pointer property.

I'll defer to others to decide whether it's worth it, as I'm ambivalent :)

Cheers,
-melanie

>> This is all just MHO. If most other people think that hw_input_bus is
>> the clearer and more user-friendly way to present this config, then I
>> will of course accept the consensus.
>>
>> Cheers,
>> -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
>>>>
>>>> [1] https://review.opendev.org/#/c/756552/ 
>>>> <https://review.opendev.org/#/c/756552/>
>>>>
>>>>
>>>
>>>
>>>
>>
> 




More information about the openstack-discuss mailing list