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