Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/22/2010 11:59 AM, Ingo Molnar wrote:
>
> Ok, that sounds interesting! I'd rather see some raw mechanism that 'perf kvm'
> could use instead of having to require yet another library (which generally
> dampens adoption of a tool). So i think we can work from there.
>    

You can access the protocol directly if you don't want a library dependency.

> Btw., have you considered using Qemu's command name (task->comm[]) as the
> symbolic name? That way we could see the guest name in 'top' on the host - a
> nice touch.
>    

qemu-system-x86_64 -name Fedora,process=qemu-Fedora

Does exactly that.  We don't make this default based on the element of 
least surprise.  Many users expect to be able to do killall 
qemu-system-x86 and if we did this by default, that wouldn't work.

>> The sockets are named based on UUID and you'll have to connect to a guest
>> and ask it for it's name.  Some guests don't have names so we'll have to
>> come up with a clever way to describe a nameless VM.
>>      
> I think just exposing the UUID in that lazy case would be adequate? It creates
> pressure for VM launchers to use better symbolic names.
>    

Yup.

>>> I.e.:
>>>
>>>   - Easy default reference to guest instances, and a way for tools to
>>>     reference them symbolically as well in the multi-guest case. Preferably
>>>     something trustable and kernel-provided - not some indirect information
>>>     like a PID file created by libvirt-manager or so.
>>>        
>> A guest is not a KVM concept.  It's a qemu concept so it needs to be
>> something provided by qemu.  The other caveat is that you won't see guests
>> created by libvirt because we're implementing this in terms of a default QMP
>> device and libvirt will disable defaults.  This is desired behaviour.
>> libvirt wants to be in complete control and doesn't want a tool like perf
>> interacting with a guest directly.
>>      
> Hm, this sucks for multiple reasons. Firstly, perf isnt a tool that
> 'interacts', it's an observation tool: just like 'top' is an observation tool.
>
> We want to enable developers to see all activities on the system - regardless
> of who started the VM or who started the process. Imagine if we had a way to
> hide tasks to hide from 'top'. It would be rather awful.
>
> Secondly, it tells us that the concept is fragile if it doesnt automatically
> enumerate all guests, regardless of how they were created.
>    

Perf does interact with a guest though because it queries a guest to 
read it's file system.

I understand the point you're making though.  If instead of doing a pull 
interface where the host queries the guest for files, if the guest 
pushed a small set of files at startup which the host cached, then you 
could potentially unconditionally expose a "read-only" socket that only 
exposed limited information.

> Full system enumeration is generally best left to the kernel, as it can offer
> coherent access.
>    

I don't see why qemu can't offer coherent access.  The limitation today 
is intentional and if it's overly restrictive, we can figure out a means 
to change it.

Regards,

Anthony Liguori


> 	Ingo
>