Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/16/2010 08:08 AM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx>  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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux