From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: KVM usability Date: Sat, 27 Feb 2010 14:30:59 +0100 Message-ID: <4B891E93.70709@web.de> References: <1267068445.1726.25.camel@localhost> <1267089644.12790.74.camel@laptop> <1267152599.1726.76.camel@localhost> <20100226090147.GH15885@elte.hu> <4B879A2F.50203@redhat.com> <20100226103545.GA7463@elte.hu> <4B87A6BF.3090301@redhat.com> <20100226111734.GE7463@elte.hu> <4B8813F2.8090208@redhat.com> <20100227105643.GA17425@elte.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5267C002B53633FB14AD53C4" Cc: Avi Kivity , Anthony Liguori , "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Zachary Amsden , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Arjan van de Ven , qemu-devel To: Ingo Molnar Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:46881 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S968306Ab0B0NbK (ORCPT ); Sat, 27 Feb 2010 08:31:10 -0500 In-Reply-To: <20100227105643.GA17425@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5267C002B53633FB14AD53C4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [ adding qemu-devel to CC as most issues concern that project as well ] Ingo Molnar wrote: > * Avi Kivity wrote: >=20 >> On 02/26/2010 01:17 PM, Ingo Molnar wrote: >>> Nobody is really 'in charge' of how KVM gets delivered to the user. Y= ou >>> isolated the fun kernel part for you and pushed out the boring bits t= o >>> user-space. So if mundane things like mouse integration sucks 'hey th= at's a >>> user-space tooling problem', if file integration sucks then 'hey, tha= t'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. >=20 > I run bleeding edge rawhide on my main desktop so i just tried latest &= =20 > greatest KVM and Qemu bits and started up kvm-qemu with some Fedora and= XP=20 > images i had around: >=20 > 2.6.33-0.44.rc8.git0.fc13.x86_64 > qemu-system-x86-0.12.2-6.fc13.x86_64 >=20 > Here's my experience with it: >=20 > - qemu-kvm starts up with a miniature resolution by default. 640x480 -= on my > 1680x1050 laptop screen. It's so small that initially i even overloo= ked=20 > that i started it. It should multiplex pixels up to a reasonable scr= een=20 > size by default. >=20 > - The mouse is trapped straight away by default if you click into it. = That's=20 > very annoying if you actually try to integrate a guest OS into your = desktop=20 > - it's not just 'another, slightly weird app' but a sticky, opiniona= ted GUI=20 > component that you have to fight with all the time. >=20 > - Once trapped it's not obvious how to untrap the mouse. The qemu wind= ow=20 > title says: >=20 > QEMU: Press Ctrl-ALT to exit grab >=20 > Of course once you _know_ what a 'grab' is, you'll know where to loo= k. > At minimum it should say: >=20 > QEMU: Press Ctrl-ALT to exit mouse grab >=20 > 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.] >=20 > - Graphics performance is awful even with the 640x480 miniature versio= n. > During bootup I can see it drawing single characters. This is a Core= 2=20 > 2.8GHz. >=20 > - Sound does not work by default. I have to go dig into command-line o= ptions > to see that i need to add: "-soundhw all". Why isnt sound enabled by= =20 > default? >=20 > - Qemu images are not integrated into the rest of the desktop. If i cl= ick on=20 > a Qemu image it says: >=20 > Could not display "/home/mingo/qemu/hda.img". >=20 > The file is of an unknown type. >=20 > 10 years of Qemu and its base image format is still 'unknown' ? >=20 > - Random bugs. I tried to boot some old Fedora image i had around, it = says: >=20 > spirit:~/qemu> qemu-kvm ./hda-fedora.img=20 > kvm: unhandled exit 80000021 > kvm_run returned -22 >=20 > Bugs happen, but more important is what a user can do with it. To a = user,=20 > 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 t= hinks > that happened? Nope - it just prints that error message (on the cons= ole, so=20 > to anyone starting it via a clicky interface wouldnt notice that the= re's=20 > something wrong) - and the guest session hanging indefinitely. >=20 > - 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-lookin= g app=20 > that flips its window size as if it was an adware popup window tryin= g to=20 > avoid being caught. >=20 > - There's no obvious way to activate paravirt drivers on the Windows s= ide. > There's no friendly "install guest drivers" button to click on with = Qemu. >=20 > _Of course_ you will end up emulating hardware in KVM (and passing i= t through > to the guest once it's clear that emulation performance sucks) and s= ooner=20 > or later you will end up requesting unreasonable things of the host = kernel=20 > to achieve that ... >=20 > - Another small detail: there is zero on-screen help (beyond the Ctrl-= ALT=20 > line) for a newbie to quickly find his way around it. No wiki addres= s, no=20 > help, no nothing. There's not even any hint about what this window d= oes.=20 > Which guest is it? In what state is that guest? >=20 > - But i'm a more advanced user so i dont need help screens, i knew tha= t the=20 > "go full screen" hotkey is: >=20 > LeftCtrl-LeftALT-F >=20 > ... except that it is a one-way road: pressing it for a second time = does=20 > not restore the window, trapping me in the guest altogether! Ctrl-AL= T does=20 > not exit the trap either. I had to shut down the guest to get back m= y X=20 > desktop. >=20 > etc., etc. >=20 > ( I could go on and on about finer details of good integration, like th= e=20 > difficulty of integrating host/guest files, networking, no way to qui= ckly=20 > attach ISOs via that window, no way to activate networking, sound and= no way=20 > to snapshot, no way to increase memory size except a command line opt= ion. ) >=20 > etc - but that's not the point really: i only spent 10 minutes on this = and i=20 > didnt try hard at all - _11_ bugs/annoyances from all across the functi= onality=20 > spectrum. >=20 > And the thing is _me_ reporting bugs does not matter at all in this pic= ture,=20 > so please dont come with "why didnt you report this?". >=20 > _Anyone_ with half a brain who takes a critical look at this virtualiza= tion=20 > solution would notice the same. Still, it's essentially unchanged from = 5 years=20 > ago. >=20 > Why is that so? I have outlined my opinion that this is due to the arti= ficial=20 > package separation / over-modularization and no-one really being in cha= rge of=20 > "KVM quality as a whole" - and i'm wondering what your theory is how su= ch a=20 > state of affairs became possible. >=20 > I'm not trolling you at all: is it _really_ not obvious to you that the= =20 > KVM/qemu usability status quo honestly sucks, to an unbiased observer? >=20 > And AFAICS KVM developers keep concentrating on all the wrong things du= e to=20 > that bad split/packaging: writing newer and newer low level kernel patc= hes and=20 > optimizations which are nice but in large part irrelevant because the=20 > _fundamental basics_ of usability suck so much ... But to you it's prob= ably=20 > just another external package so not really something you can do much a= bout,=20 > right? Yes, there are quite a few frontends around, also for desktop virtualization. AQEMU [1], e.g., should address at least some of your valuable usability criticisms. If GUIs are not yet optimally integrated with QEMU and if there is something that can be done inside QEMU or even KVM, let's discuss that together with the related communities. However, that is definitely not a valid reason for KVM developers to stop improving the virtualization core for demanding use cases and start writing GUIs. Likely it is unfortunate that there is not The One And Only graphical frontend for the desktop scenario we can focus on (But is it unfortunate for desktop Linux that there is still Gnome vs. KDE? I bet there are zillion opinions on that.). But maybe this discussion here will have the positive effect that the QEMU/KVM community starts giving more feedback to some of those projects, and vice versa. >=20 > Really, the KVM design is so nice in many regards and Qemu has come for= ward=20 > leaps and bounds in the past few years as well, how can you miss such b= asic=20 > areas of weakness? 'First impression' is the thing that gives you new=20 > developers - it's any OSS project's bread and butter. 'First impression' mostly gives us more users - a worthwhile goal as well= ! But developers are rather attracted by rich features, a flexible, extensible design, a working community and - of course - a proper licensing model. Look at Virtualbox, they probably meet your usability requirements out of the box. Do they have a developer community? Not at all because they miss some of that key requirements. Also for those reasons, Vbox dropped from the list of candidates for many virtualization projects @work, and we decided to invest in the true Linux stack. Jan [1] http://sourceforge.net/projects/aqemu/ --------------enig5267C002B53633FB14AD53C4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuJHpwACgkQitSsb3rl5xTKswCgiwFAyfGyt058ONBsJLSomtXp 1GEAoNhXdQfRQSk/HXnL2gy5B1JILS5H =i/32 -----END PGP SIGNATURE----- --------------enig5267C002B53633FB14AD53C4-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlMlK-00073J-Hb for qemu-devel@nongnu.org; Sat, 27 Feb 2010 08:31:19 -0500 Received: from [199.232.76.173] (port=35685 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlMlJ-00072n-RB for qemu-devel@nongnu.org; Sat, 27 Feb 2010 08:31:17 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NlMlE-00079o-Sx for qemu-devel@nongnu.org; Sat, 27 Feb 2010 08:31:17 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:46908) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NlMlE-00079a-5H for qemu-devel@nongnu.org; Sat, 27 Feb 2010 08:31:12 -0500 Message-ID: <4B891E93.70709@web.de> Date: Sat, 27 Feb 2010 14:30:59 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1267068445.1726.25.camel@localhost> <1267089644.12790.74.camel@laptop> <1267152599.1726.76.camel@localhost> <20100226090147.GH15885@elte.hu> <4B879A2F.50203@redhat.com> <20100226103545.GA7463@elte.hu> <4B87A6BF.3090301@redhat.com> <20100226111734.GE7463@elte.hu> <4B8813F2.8090208@redhat.com> <20100227105643.GA17425@elte.hu> In-Reply-To: <20100227105643.GA17425@elte.hu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5267C002B53633FB14AD53C4" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: KVM usability List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ingo Molnar Cc: "Zhang, Yanmin" , "H. Peter Anvin" , KVM General , ming.m.lin@intel.com, Peter Zijlstra , sheng.yang@intel.com, Zachary Amsden , qemu-devel , Gleb Natapov , Arnaldo Carvalho de Melo , Avi Kivity , Jes Sorensen , Thomas Gleixner , Arjan van de Ven , Fr??d??ric Weisbecker , Peter Zijlstra This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5267C002B53633FB14AD53C4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [ adding qemu-devel to CC as most issues concern that project as well ] Ingo Molnar wrote: > * Avi Kivity wrote: >=20 >> On 02/26/2010 01:17 PM, Ingo Molnar wrote: >>> Nobody is really 'in charge' of how KVM gets delivered to the user. Y= ou >>> isolated the fun kernel part for you and pushed out the boring bits t= o >>> user-space. So if mundane things like mouse integration sucks 'hey th= at's a >>> user-space tooling problem', if file integration sucks then 'hey, tha= t'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. >=20 > I run bleeding edge rawhide on my main desktop so i just tried latest &= =20 > greatest KVM and Qemu bits and started up kvm-qemu with some Fedora and= XP=20 > images i had around: >=20 > 2.6.33-0.44.rc8.git0.fc13.x86_64 > qemu-system-x86-0.12.2-6.fc13.x86_64 >=20 > Here's my experience with it: >=20 > - qemu-kvm starts up with a miniature resolution by default. 640x480 -= on my > 1680x1050 laptop screen. It's so small that initially i even overloo= ked=20 > that i started it. It should multiplex pixels up to a reasonable scr= een=20 > size by default. >=20 > - The mouse is trapped straight away by default if you click into it. = That's=20 > very annoying if you actually try to integrate a guest OS into your = desktop=20 > - it's not just 'another, slightly weird app' but a sticky, opiniona= ted GUI=20 > component that you have to fight with all the time. >=20 > - Once trapped it's not obvious how to untrap the mouse. The qemu wind= ow=20 > title says: >=20 > QEMU: Press Ctrl-ALT to exit grab >=20 > Of course once you _know_ what a 'grab' is, you'll know where to loo= k. > At minimum it should say: >=20 > QEMU: Press Ctrl-ALT to exit mouse grab >=20 > 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.] >=20 > - Graphics performance is awful even with the 640x480 miniature versio= n. > During bootup I can see it drawing single characters. This is a Core= 2=20 > 2.8GHz. >=20 > - Sound does not work by default. I have to go dig into command-line o= ptions > to see that i need to add: "-soundhw all". Why isnt sound enabled by= =20 > default? >=20 > - Qemu images are not integrated into the rest of the desktop. If i cl= ick on=20 > a Qemu image it says: >=20 > Could not display "/home/mingo/qemu/hda.img". >=20 > The file is of an unknown type. >=20 > 10 years of Qemu and its base image format is still 'unknown' ? >=20 > - Random bugs. I tried to boot some old Fedora image i had around, it = says: >=20 > spirit:~/qemu> qemu-kvm ./hda-fedora.img=20 > kvm: unhandled exit 80000021 > kvm_run returned -22 >=20 > Bugs happen, but more important is what a user can do with it. To a = user,=20 > 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 t= hinks > that happened? Nope - it just prints that error message (on the cons= ole, so=20 > to anyone starting it via a clicky interface wouldnt notice that the= re's=20 > something wrong) - and the guest session hanging indefinitely. >=20 > - 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-lookin= g app=20 > that flips its window size as if it was an adware popup window tryin= g to=20 > avoid being caught. >=20 > - There's no obvious way to activate paravirt drivers on the Windows s= ide. > There's no friendly "install guest drivers" button to click on with = Qemu. >=20 > _Of course_ you will end up emulating hardware in KVM (and passing i= t through > to the guest once it's clear that emulation performance sucks) and s= ooner=20 > or later you will end up requesting unreasonable things of the host = kernel=20 > to achieve that ... >=20 > - Another small detail: there is zero on-screen help (beyond the Ctrl-= ALT=20 > line) for a newbie to quickly find his way around it. No wiki addres= s, no=20 > help, no nothing. There's not even any hint about what this window d= oes.=20 > Which guest is it? In what state is that guest? >=20 > - But i'm a more advanced user so i dont need help screens, i knew tha= t the=20 > "go full screen" hotkey is: >=20 > LeftCtrl-LeftALT-F >=20 > ... except that it is a one-way road: pressing it for a second time = does=20 > not restore the window, trapping me in the guest altogether! Ctrl-AL= T does=20 > not exit the trap either. I had to shut down the guest to get back m= y X=20 > desktop. >=20 > etc., etc. >=20 > ( I could go on and on about finer details of good integration, like th= e=20 > difficulty of integrating host/guest files, networking, no way to qui= ckly=20 > attach ISOs via that window, no way to activate networking, sound and= no way=20 > to snapshot, no way to increase memory size except a command line opt= ion. ) >=20 > etc - but that's not the point really: i only spent 10 minutes on this = and i=20 > didnt try hard at all - _11_ bugs/annoyances from all across the functi= onality=20 > spectrum. >=20 > And the thing is _me_ reporting bugs does not matter at all in this pic= ture,=20 > so please dont come with "why didnt you report this?". >=20 > _Anyone_ with half a brain who takes a critical look at this virtualiza= tion=20 > solution would notice the same. Still, it's essentially unchanged from = 5 years=20 > ago. >=20 > Why is that so? I have outlined my opinion that this is due to the arti= ficial=20 > package separation / over-modularization and no-one really being in cha= rge of=20 > "KVM quality as a whole" - and i'm wondering what your theory is how su= ch a=20 > state of affairs became possible. >=20 > I'm not trolling you at all: is it _really_ not obvious to you that the= =20 > KVM/qemu usability status quo honestly sucks, to an unbiased observer? >=20 > And AFAICS KVM developers keep concentrating on all the wrong things du= e to=20 > that bad split/packaging: writing newer and newer low level kernel patc= hes and=20 > optimizations which are nice but in large part irrelevant because the=20 > _fundamental basics_ of usability suck so much ... But to you it's prob= ably=20 > just another external package so not really something you can do much a= bout,=20 > right? Yes, there are quite a few frontends around, also for desktop virtualization. AQEMU [1], e.g., should address at least some of your valuable usability criticisms. If GUIs are not yet optimally integrated with QEMU and if there is something that can be done inside QEMU or even KVM, let's discuss that together with the related communities. However, that is definitely not a valid reason for KVM developers to stop improving the virtualization core for demanding use cases and start writing GUIs. Likely it is unfortunate that there is not The One And Only graphical frontend for the desktop scenario we can focus on (But is it unfortunate for desktop Linux that there is still Gnome vs. KDE? I bet there are zillion opinions on that.). But maybe this discussion here will have the positive effect that the QEMU/KVM community starts giving more feedback to some of those projects, and vice versa. >=20 > Really, the KVM design is so nice in many regards and Qemu has come for= ward=20 > leaps and bounds in the past few years as well, how can you miss such b= asic=20 > areas of weakness? 'First impression' is the thing that gives you new=20 > developers - it's any OSS project's bread and butter. 'First impression' mostly gives us more users - a worthwhile goal as well= ! But developers are rather attracted by rich features, a flexible, extensible design, a working community and - of course - a proper licensing model. Look at Virtualbox, they probably meet your usability requirements out of the box. Do they have a developer community? Not at all because they miss some of that key requirements. Also for those reasons, Vbox dropped from the list of candidates for many virtualization projects @work, and we decided to invest in the true Linux stack. Jan [1] http://sourceforge.net/projects/aqemu/ --------------enig5267C002B53633FB14AD53C4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuJHpwACgkQitSsb3rl5xTKswCgiwFAyfGyt058ONBsJLSomtXp 1GEAoNhXdQfRQSk/HXnL2gy5B1JILS5H =i/32 -----END PGP SIGNATURE----- --------------enig5267C002B53633FB14AD53C4--