Messages in this thread | | | Date | Tue, 16 Mar 2010 12:06:19 -0500 | From | Anthony Liguori <> | Subject | Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side |
| |
On 03/16/2010 08:08 AM, Ingo Molnar wrote: > * Avi Kivity<avi@redhat.com> wrote: > > >> On 03/16/2010 02:29 PM, Ingo Molnar wrote: >> > >>> I mean, i can trust a kernel service and i can trust /proc/kallsyms. >>> >>> Can perf trust a random process claiming to be Qemu? What's the trust >>> mechanism here? >>> >> Obviously you can't trust anything you get from a guest, no matter how you >> get it. >> > I'm not talking about the symbol strings and addresses, and the object > contents for allocation (or debuginfo). I'm talking about the basic protocol > of establishing which guest is which. > > I.e. we really want to be able users to: > > 1) have it all working with a single guest, without having to specify 'which' > guest (qemu PID) to work with. That is the dominant usecase both for > developers and for a fair portion of testers. >
You're making too many assumptions.
There is no list of guests anymore than there is a list of web browsers.
You can have a multi-tenant scenario where you have distinct groups of virtual machines running as unprivileged users.
> 2) Have some reasonable symbolic identification for guests. For example a > usable approach would be to have 'perf kvm list', which would list all > currently active guests: > > $ perf kvm list > [1] Fedora > [2] OpenSuse > [3] Windows-XP > [4] Windows-7 > > And from that point on 'perf kvm -g OpenSuse record' would do the obvious > thing. Users will be able to just use the 'OpenSuse' symbolic name for > that guest, even if the guest got restarted and switched its main PID. >
Does "perf kvm list" always run as root? What if two unprivileged users both have a VM named "Fedora"?
If we look at the use-case, it's going to be something like, a user is creating virtual machines and wants to get performance information about them.
Having to run a separate tool like perf is not going to be what they would expect they had to do. Instead, they would either use their existing GUI tool (like virt-manager) or they would use their management interface (either QMP or libvirt).
The complexity of interaction is due to the fact that perf shouldn't be a stand alone tool. It should be a library or something with a programmatic interface that another tool can make use of.
Regards,
Anthony Liguori
> Is such a scheme possible/available? I suspect all the KVM configuration tools > (i havent used them in some time - gui and command-line tools alike) use > similar methods to ease guest management? > > Ingo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
| |