Re: KVM usability

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/27/2010 04: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
>    

Probably 720x480 if you're referring to CGA mode.

>     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.
>    

Resize the window to whatever size you want it to be.  We'll 
automatically scale the screen.  This works both with SDL and with VNC 
(provided you use a gtk-vnc based client).

If you're suggesting we should scale by default, I disagree.  I have the 
same size screen and the QEMU window is a little bit larger than a 
standard gnome-terminal.

>   - 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.
>    

All virtualization software behaves this way.

>   - 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
>    

Reasonable suggestion.  I've changed it in my local branch.

>     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.]
>
>   - 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.
>    

That's a bug.  Please report it.  Graphics performance isn't great, but 
it should not be that bad.

>   - 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?
>    

Because it's intrusive.  If you're running 20 guests, you don't want 
them all trying to play the Windows start up noise.  Even if you're 
running a single VM, you don't necessarily want your music interrupted 
to play the Ubuntu drums.  It's particularly annoying if you're 
repeatedly starting up guests.

>   - 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' ?
>    

It's not been 10 years, but I presume you're using a raw image or your 
distro is fubar because:

anthony@squirrel:~/images$ file linux.img
linux.img: Qemu Image, Format: Qcow , Version: 2

We intentionally don't want images to be directly executable.  An image 
doesn't include the necessary configuration information to launch a 
guest.  Adding that info to an image is not an obvious thing to do 
either because a virtual machine may consist of multiple images.

>   - 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
>    

This error message is horrible and it warrants a bug report.   See 
https://bugs.launchpad.net/qemu/+bug/530077

>   - 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.
>    

All virtualization software does this and I think it's completely 
reasonable.  Again, you can resize the window manually and it'll keep 
that resolution if you are so inclined.  As KMS is better supported in 
Linux guests, we'll eventually get to the point where less screen 
flipping is done.  This is as much a usability issue on bare metal as it 
is in a VM.

>   - 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 ...
>    

This is a licensing issue.  You cannot just build Windows drivers 
anymore.  They need to be signed by Microsoft in order to be loadable in 
the most recent versions of Windows.  If you look at the recent Fedora 
Advisory Board minutes, you'll see that this issue has been discussed 
specifically around how a distribution like Fedora can provide Windows 
drivers to end users in a friendly way.

I believe the current proposal is to host a signed binary on a site like 
Fedora Hosted, and then have virt-manager automatically download the ISO 
on demand.  Shipping the binary ISO as part of a distribution package 
though is not possible since it cannot be rebuilt like any other package.

>   - 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?
>    

This is a valid criticism but is tied to the fact that we use SDL.

>   - 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.
>    

That's a bug.

> 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.
>
> I'm not trolling you at all: is it _really_ not obvious to you that the
> KVM/qemu usability status quo honestly sucks, to an unbiased observer?
>
> And AFAICS KVM developers keep concentrating on all the wrong things due to
> that bad split/packaging: writing newer and newer low level kernel patches and
> optimizations which are nice but in large part irrelevant because the
> _fundamental basics_ of usability suck so much ... But to you it's probably
> just another external package so not really something you can do much about,
> right?
>
> Really, the KVM design is so nice in many regards and Qemu has come forward
> leaps and bounds in the past few years as well, how can you miss such basic
> areas of weakness? 'First impression' is the thing that gives you new
> developers - it's any OSS project's bread and butter.
>    

Ultimately, the problem you're facing is choice.  It's the same problem 
that faces a lot of other open source projects.

Your expectation of QEMU/KVM is that the graphics experience is 
optimized for a casual desktop virtualization user.  That is not the 
goal of QEMU/KVM though.  That is the goal of virt-manager.  The real 
question to ask is, why are you using qemu directly instead of using 
virt-manager?

Qemu targets two types of users.  The first is third party management 
interfaces.  Qemu can be used for a lot of purposes beyond desktop 
virtualization.  Most cell phone SDKs use qemu arm emulation.  The 
interface for a cell phone SDK is obviously very different from the 
interface for desktop virtualization.  Taking the gui out of qemu lets 
us support both.

It makes very little sense to integrate a powerful gui directly into 
qemu because in many circumstances, the qemu instance that you are 
interacting with is on a completely different box.  This is where 
something like virt-manager comes into play because you can just as 
easily manage a remote instance of qemu as a local one.

The other type of user we target is power virtualization/emulation 
users.  We certainly could do better for this type of user but it's 
never going to fit what your expectation of desktop virtualization is.  
Qemu is never going to be like running VMware Workstation or VirtualBox.

There is very little split between qemu and kvm from a project 
perspective.  If anything, our lack of focus on desktop virtualization 
comes from the split between qemu/kvm and libvirt.  All of the end-user 
usability is done in the context of libvirt and virt-manager whereas the 
qemu/kvm developers tend to focus on performance, features, and robustness.

I think we don't spend enough time in qemu/kvm thinking about how we 
interact with libvirt with respect to end-to-end usability.  It's 
something I do believe we need to address and it's an area I have been 
focusing on recently.

Regards,

Anthony Liguori

> Thanks,
>
> 	Ingo
>