Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Antoine Martin on 22 Mar 2010 08:10 [snip] >>> I believe that -kernel use will be rare, though. It's a lot >>> easier to keep everything in one filesystem. >> Well, for what it's worth, I rarely ever use anything else. My >> virtual disks are raw so I can loop mount them easily, and I can also >> switch my guest kernels from outside... without ever needing to mount >> those disks. > > Curious, what do you use them for? Various things, here is one use case which I think is under-used: read-only virtual disks with just one network application on them (no runlevels, sshd, user accounts, etc), a hell of a lot easier to maintain and secure than a full blown distro. Want a new kernel? boot a new VM and swap it for the old one with zero downtime (if your network app supports this sort of hot-swap - which a lot of cluster apps do) Another reason for wanting to keep the kernel outside is to limit the potential points of failure: remove the partition table, remove the bootloader, remove even the ramdisk. Also makes it easier to switch to another solution (say UML) or another disk driver (as someone mentioned previously). In virtualized environments I often prefer to remove the ability to load kernel modules too, for obvious reasons. Hope this helps. Antoine -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 22 Mar 2010 08:30 On 03/22/2010 01:14 PM, Ingo Molnar wrote: > >> I think we agree at last. Neither I nor my employer are interested in >> running qemu as a desktop-on-desktop tool, therefore I don't invest any >> effort in that direction, or require it from volunteers. >> > Obviously your employer at least in part defers to you when it comes to KVM > priorities. > In part, yes. > So, just to make this really clear, _you_ are not interested in running qemu > as a desktop-on-desktop tool, subsequently this kind of > disinterest-for-desktop-usability trickled through the whole KVM stack and > poisoned your attitude and your contributor's attitude. > I am also disinterested in ppc virtualization, yet it happened. I am disinterested in ia64 virtualization, yet it happened. I am disinterested in s390 virtualization, yet it happened. Linus doesn't care about virtualization, yet it happened. I don't tell my contributor what to be interested in, only whether their patches are good or not. I can tell you that Red Hat contributors don't work on a desktop kvm GUI not because I discourage them, but because the product we are working on does not contain a desktop kvm GUI. Jan Kiszka contributed a lot of debugger features, fixes, and improvement, presumably he and/or his employer need that more than a kvm desktop GUI. I can't see why you see anything wrong with this. People write patches for their own interest, not yours or mine. > Too sad really and it's doubly sad that you dont feel anything wrong about > that. > It would be lovely to have a desktop kvm GUI. I don't feel I have to write it myself or compel others to write it. I don't feel sad about it. >> If you think a good GUI is so badly needed, either write one yourself, or >> convince someone else to do it. >> > To a certain degree we are trying to do a small bit of that (see this very > thread) - and you are NAK-ing and objecting the heck out of it via your > unreasonable microkernelish and server-centric views. > The perf bits have nothing to do with a GUI or usability for general users. Calling them "unreasonable microkernelish sever-centric views" is just a way of not addressing them. > With constant maintainer disinterest there's no wonder a non-desktop-oriented > KVM becomes a self-fulfilling prophecy: you think the desktop does not matter, > hence it becomes a reality in KVM space which you can constantly refer back to > as a 'fact'. > It's a fact that virtualization is happening in the data center, not on the desktop. You think a kvm GUI can become a killer application? fine, write one. You don't need any consent from me as kvm maintainer (if patches are needed to kvm that improve the desktop experience, I'll accept them, though they'll have to pass my unreasonable microkernelish filters). If you're right then the desktop kvm GUI will be a huge hit with zillions of developers and people will drop Windows and switch to Linux just to use it. But my opinion is that it will end up like virtualbox, a nice app that you can use to run Windows-on-Linux, but is not all that useful. > Which i find dishonest and disingenious at best. > If you're going to use words like 'dishonest' then please don't send me any more email. >> (btw, why are you interested in desktop-on-desktop? one use case is >> developers, which don't really need fancy GUIs; a second is people who test >> out distributions, but that doesn't seem to be a huge population; and a >> third is people running Windows for some application that doesn't run on >> Linux - hopefully a small catergory as well. Seems to be quite a small >> target audience, compared to, say, video editing) >> > I'm interested in desktop-on-desktop because i walk this world with open eyes > and i care about Linux, and these days qemu-kvm is the first thing a new Linux > user sees about Linux virtualization. I've observed several people i know in > person to turn away from Linux and go back to Windows or go over to Apple > because they had a much more mature solution. > Which distribution are they using? Most people would see virt-manager as the first thing, not open gnome-terminal and start typing in the qemu command line. While it's not perfect, it does have a shiny GUI with lots of tabs and buttons. > I'd probably turn away from Linux myself if i were a newbie and if i were > forced to use KVM on the desktop today. > > Again, you dont seem to realize that you as a maintainer are at a central > point where you have the ability to turn the self-fulfilling prophecy that > 'nobody cares about the Linux desktop' into a reality - or where you have the > ability to prevent it from happening. It is hugely harmful process, especially > as you seem to delude yourself that you have nothing to do with it. > It doesn't have to be me. Better to pick someone who has a clue about usability to design and guide this effort. That someone can work on qemu, or if they prefer, tools/kvm (we worked hard to avoid making kvm tied to a single userspace). The kvm toolstack is maintained by multiple people - Marcelo and myself at the kernel level, Anthony and the other qemu maintainers at the qemu single-guest level, Daniel Veillard and Dan Berrange at the libvirt or host level, and Cole Robinson at the virt-manager or GUI level. It's unreasonable to ask one person to do all of this, just like Linus doesn't maintain the scheduler even though it is so important. > Anyway, it's good you expressed your views about this as this will help the > chances of a fresh restart. (which chances are still not too good though) > All that's needed is to find someone with the skills, time, and interest. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 08:30 * oerg Roedel <joro(a)8bytes.org> wrote: > On Sun, Mar 21, 2010 at 09:31:21PM +0100, Ingo Molnar wrote: > > Lets see one example of that thought process in action: Oprofile. > > Since you are talking so much about oProfile in this thread I think it is > important to mention that the problem with oProfile was not the repository > separation. > > The problem was (and is) that the kernel and the user-space parts are > maintained by different people [...] Caused by: repository separation and the inevitable code and social fork a decade later. > [...] who dont talk to each other or have a direction where they want to go > with the project. [...] Caused by: repository separation and the inevitable code and social fork a decade later. > [...] Basically the reason of the oProfile failure is a disfunctional > community. [...] Caused by: repository separation and the inevitable code and social fork a decade later. > [...] I told the kernel-maintainer several times to also maintain > user-space but he didn't want that. > > The situation with KVM is entirely different. Avi commits to kvm.git and > qemu-kvm.git so he maintains both. [...] What you fail to realise (or what you fail to know, you werent around when Oprofile was written, i was) is that Oprofile _did_ have a functional single community when it was written. The tooling and the kernel bits was written by the same people. But a decade is a long time and the drift happened due to the inevitability of the repository separation, and due to the _inability_ to reach a sane, usable solution within that framework of separation. So i dont see much of a difference to the Oprofile situation really and i see many parallels. I also see similar kinds of desktop usability problems. The difference is that we dont have KVM with a decade of history and we dont have a 'told you so' KVM reimplementation to show that proves the point. I guess it's a matter of time before that happens, because Qemu usability is so absymal today - so i guess we should suspend any discussions until that happens, no need to waste time on arguing hypoteticals. I think you are rationalizing the status quo. It's as if you argued in 1990 that the unification of East and West Germany wouldnt make much sense because despite clear problems and incompatibilites and different styles westerners were still allowed to visit eastern relatives and they both spoke the same language after all ;-) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 22 Mar 2010 08:40 On 03/22/2010 01:48 PM, Ingo Molnar wrote: > * Avi Kivity<avi(a)redhat.com> wrote: > > >>> My 10+ years experience with kernel instrumentation solutions is that >>> kernel-driven, self-sufficient, robust, trustable, well-enumerated sources >>> of information work far better in practice. >>> >> What about line number information? And the source? Into the kernel with >> them as well? >> > Sigh. Please read the _very first_ suggestion i made, which solves all that. I > rarely go into discussions without suggesting technical solutions - i'm not > interested in flaming, i'm interested in real solutions. > > Here it is, repeated for the Nth time: > > Allow a guest to (optionally) integrate its VFS namespace with the host side > as well. An example scheme would be: > > /guests/Fedora-G1/ > [...] You're missing something. This sub-thread is about someone launching a kernel with 'qemu -kernel', the kernel lives outside the guest disk image, they don't want a custom initrd because it's hard to make. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 22 Mar 2010 08:50
On 03/22/2010 01:39 PM, Ingo Molnar wrote: > Reality is, the server space never was and never will be self-sustaining in > the long run (as Novell has found it out with Netware), it is the desktop that > dictates future markets. This is why i find your views about this naive and > shortsighted. > Yet Linux is gaining ground in the server and embedded space while struggling on the desktop. Apple is gaining ground on the desktop but is invisible on the server side (despite having a nice product - Xserve). It's true Windows achieved server dominance through it's desktop power, but I don't think that's what keeping them there now. In any case, I'm not going to write a kvm GUI. It doesn't match my skills, interest, or my employer's interest. If you wish to see a kvm GUI you have to write one yourself or convince someone to write it (perhaps convince Red Hat to fund such an effort beyond virt-manager). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |