Re: Enhance perf to support KVM

Ingo Molnar
2010-02-26T11:18:10Z

* Avi Kivity <avi@redhat.com> 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.

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.

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.

Sure the design looks somewhat cleaner on paper, but if the end result is not
helped by it then over-modularization sure can hurt ...

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

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

So i can see some upcoming culture friction with standing KVM principles there
;-)

Ingo