Re: KVM usability

[Zachary Amsden <zamsden@redhat.com>]

On 02/27/2010 12:56 AM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>> On 02/26/2010 01:17 PM, Ingo Molnar wrote:
>>      
>>> Nobody is really 'in charge' of how KVM gets delivered to the user. You
>>> isolated the fun kernel part for you and pushed out the boring bits to
>>> user-space. So if mundane things like mouse integration sucks 'hey that's a
>>> user-space tooling problem', if file integration sucks then 'hey, that's an
>>> admin problem', if it cannot be used over the network 'hey, that's an Xorg
>>> problem', etc. etc.
>>>        
>> btw, mouse integration works with -usbdevice tablet and recent
>> Fedoras, 'it was an X.org driver problem'.
>>
>> Really, I don't understand your problems.
>>      
> I run bleeding edge rawhide on my main desktop so i just tried latest&
> greatest KVM and Qemu bits and started up kvm-qemu with some Fedora and XP
> images i had around:
>
>    2.6.33-0.44.rc8.git0.fc13.x86_64
>    qemu-system-x86-0.12.2-6.fc13.x86_64
>
> Here's my experience with it:
>
>   - qemu-kvm starts up with a miniature resolution by default. 640x480 - on my
>     1680x1050 laptop screen. It's so small that initially i even overlooked
>     that i started it. It should multiplex pixels up to a reasonable screen
>     size by default.
>    

No virtualization emulator today does this, it is not a reasonable thing 
to do.  Unless you are running compiz and use hardware scaling.  We 
should look into it.

>   - The mouse is trapped straight away by default if you click into it. That's
>     very annoying if you actually try to integrate a guest OS into your desktop
>     - it's not just 'another, slightly weird app' but a sticky, opinionated GUI
>     component that you have to fight with all the time.
>
>   - Once trapped it's not obvious how to untrap the mouse. The qemu window
>     title says:
>
>            QEMU: Press Ctrl-ALT to exit grab
>
>     Of course once you _know_ what a 'grab' is, you'll know where to look.
>     At minimum it should say:
>
>            QEMU: Press Ctrl-ALT to exit mouse grab
>
>     But to first-time users it's an annoying trap of the mouse and with no
>     obvious place to look for help. [besides, it doesnt tell which Ctrl and
>     which ALT to use - it's the left side. The right side Ctrl does not work.]
>    

As a long time user of other brand name virtualization software, this 
was immediately obvious to me and followed the paradigm I was used to - 
a two or three combination meta key press allows escape, while allowing 
you to send one or two combo meta keypresses to the VM.

>   - Graphics performance is awful even with the 640x480 miniature version.
>     During bootup I can see it drawing single characters. This is a Core2
>     2.8GHz.
>    

Yes it is.

>   - Sound does not work by default. I have to go dig into command-line options
>     to see that i need to add: "-soundhw all". Why isnt sound enabled by
>     default?
>    

Probably because qemu as a platform supports 800 different kinds of 
hosts, all with their own sound solutions, sometimes integrated "for 
ease" as part of the display library, sometimes split into a myriad of 
confusing and incompatible options, like on Linux.

>   - Qemu images are not integrated into the rest of the desktop. If i click on
>     a Qemu image it says:
>
>       Could not display "/home/mingo/qemu/hda.img".
>
>       The file is of an unknown type.
>
>     10 years of Qemu and its base image format is still 'unknown' ?
>    

This is a desktop distro issue and easily fixed.  Please file a bug.

>   - Random bugs. I tried to boot some old Fedora image i had around, it says:
>
>       spirit:~/qemu>  qemu-kvm ./hda-fedora.img
>       kvm: unhandled exit 80000021
>       kvm_run returned -22
>
>     Bugs happen, but more important is what a user can do with it. To a user,
>     what does this tell? Is it actionable? Does it give any URL to check? Any bug
>     submit mechanism to follow? Does it even tell what the code itself thinks
>     that happened? Nope - it just prints that error message (on the console, so
>     to anyone starting it via a clicky interface wouldnt notice that there's
>     something wrong) - and the guest session hanging indefinitely.
>    

Qemu code is very bad in general at error handling.  It will take years 
to fix this.

>   - When it boots up, the Qemu window flips around its size crazily, as the BIOS,
>     the bootloader and the OS sets different screen resolutions. To the user that
>     technical detail is immaterial, what matters is an amateurish-looking app
>     that flips its window size as if it was an adware popup window trying to
>     avoid being caught.
>    

This is true again of other major brand name virtualization solutions.  
The window resizes as the guest resizes the display.  There really isn't 
a better solution.

>   - There's no obvious way to activate paravirt drivers on the Windows side.
>     There's no friendly "install guest drivers" button to click on with Qemu.
>
>     _Of course_ you will end up emulating hardware in KVM (and passing it through
>     to the guest once it's clear that emulation performance sucks) and sooner
>     or later you will end up requesting unreasonable things of the host kernel
>     to achieve that ...
>
>   - Another small detail: there is zero on-screen help (beyond the Ctrl-ALT
>     line) for a newbie to quickly find his way around it. No wiki address, no
>     help, no nothing. There's not even any hint about what this window does.
>     Which guest is it? In what state is that guest?
>    

These are productized refinements we should look at implementing.

>   - But i'm a more advanced user so i dont need help screens, i knew that the
>     "go full screen" hotkey is:
>
>             LeftCtrl-LeftALT-F
>
>     ... except that it is a one-way road: pressing it for a second time does
>     not restore the window, trapping me in the guest altogether! Ctrl-ALT does
>     not exit the trap either. I had to shut down the guest to get back my X
>     desktop.
>
> etc., etc.
>
> ( I could go on and on about finer details of good integration, like the
>    difficulty of integrating host/guest files, networking, no way to quickly
>    attach ISOs via that window, no way to activate networking, sound and no way
>    to snapshot, no way to increase memory size except a command line option. )
>
> etc - but that's not the point really: i only spent 10 minutes on this and i
> didnt try hard at all - _11_ bugs/annoyances from all across the functionality
> spectrum.
>
> And the thing is _me_ reporting bugs does not matter at all in this picture,
> so please dont come with "why didnt you report this?".
>
> _Anyone_ with half a brain who takes a critical look at this virtualization
> solution would notice the same. Still, it's essentially unchanged from 5 years
> ago.
>
> Why is that so? I have outlined my opinion that this is due to the artificial
> package separation / over-modularization and no-one really being in charge of
> "KVM quality as a whole" - and i'm wondering what your theory is how such a
> state of affairs became possible.
>    

This is really packed with a bunch of loaded statements.

First of all, the package separation is not artificial, it is a natural 
consequence of the architecture.  There is a CPU, it manipulates and is 
tightly integrated with memory, and there are devices which are part of 
the chipset, and so on.

Second, it's not over-modularized.  The modules are the individual 
components of the architecture.  How would you propose to put it 
differently.  They really can't naturally combine.  And with the code 
quality of qemu in general being problematic by Linux kernel standards, 
it's not natural to move the device emulation directly into the kernel 
module.  So this is why we are where we are today.

Third, it's the maintainers upstream who are in charge of KVM quality as 
a whole - when you are talking about upstream code quality, and the 
package maintainers who are in charge of KVM quality as a whole - when 
you are talking about a distro.  This is nothing new - it's just a 
statement of decentralization.

Zach