On 02/26/2010 01:17 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:
Do you have (or plan) any turn-key 'access to all files of the guest' kind
of guest-transparent facility that could be used for such purposes?
Not really. The guest and host admins are usually different people, who
may, being admins, even actively hate each other. The guest admin would
probably regard it as a security hole. It's probably useful for the
single-host scenario, and of course for developers.
Sounds like an exceedingly silly argument to me - the host admin is the king
in any case.
Your argument boils down to: 'dont offer transparent, turn-key solutions
because some might object to the functionality they offer for all the wrong
reasons'. Which does not withstand elementary scrutiny.
Again, the host admin and the guest admin are different people. What
would the host admin do with guest files? Why would the guest admin
want to run any code that exposes their files?
This is a basic usability issue, and affects many parts of the KVM universe.
Really, it's by far the most fubar-ed notion of KVM. You are pushing _way_ too
much to user-space into different modules and maintenance domains, and
user-space forks those bits, fragments, diverts, delays and messes up basic
features in the usual fashion.
The result is a basic out-of-box virtualization experience that sucks even
these days.
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.
What would you have me do? Push 200K lines of device emulation code
into the kernel? Write an X client, toolkit, and display in the kernel
so that mouse integration works out of the box when you install Linux
2.6.653?
As to "nobody is in charge", that's really insulting to the people who
are in charge of the userspace components. Perhaps the problems that we
see are not the same problems that you see. It might be that direct
access to guest files from the host is only a pressing problem for you,
but nobody else. If there are features that you miss, post patches, if
you will deign to code for lowly user space.
You basically have given up control over the quality of KVM by pushing so many
aspects of it to user-space and letting it rot there.
That's wrong on so many levels. First, nothing is rotting in userspace,
qemu is evolving faster than kvm is. If I pushed it into the kernel
then development pace would be much slower (since kernel development is
harder), quality would be lower (less infrastructure, any bug is a host
crash or security issue), and I personally would be totally swamped.
Sure the design looks somewhat cleaner on paper, but if the end result is not
helped by it then over-modularization sure can hurt ...
Run 'rpm -qa' one of these days. Modern software is modular, that's the
only way to manage it.
( Note that i dont mind user-space tooling per se, as long as it sits together
with the kernel bits and gets developed, packaged and given to the user in
the same domain. )
Call me when glibc, the X servers and clients, and everything else qemu
now uses is developed, packaged, and given to the user in the same domain.
And that's a key conceptual area were tools/perf/ differs: it's an integrated,
turn-key solution that you can really rely on. We take responsibility for the
full thing, no ifs and when. And if you cannot rely on your instrumentation
tooling as a single unit you cannot use it, simple as that. (that is a key
mistake Oprofile made a decade ago too btw.)
perf is a tool written by developers for developers. kvm is written for
users (most of them hidden behind management interfaces). There's no
point at all in shipping it as part of the kernel, users don't install
and use kernels, they install and use distributions.
So i can see some upcoming culture friction with standing KVM principles there
;-)
No friction at all - I don't think any kvm developer agrees with you
(but if anyone does please speak up).
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
