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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B9FBA8B.8020200@codemonkey.ws>
Date:	Tue, 16 Mar 2010 12:06:19 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Avi Kivity <avi@...hat.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com
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@...hat.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/