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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/22/2010 10:55 AM, Ingo Molnar wrote:
> * Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>    
>> [...]
>>
>> I've been trying very hard to turn this into a productive thread attempting
>> to capture your feedback and give clear suggestions about how you can solve
>> achieve your desired functionality.
>>      
> I'm glad that we are at this more productive stage. I'm still trying to
> achieve the very same technological capabilities that i expressed in the first
> few mails when i reviewed the 'perf kvm' patch that was submitted by Yanmin.
>
> The crux of the problem is very simple. To quote my earlier mail:
>
>   |
>   | - The inconvenience of having to type:
>   |      perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms \
>   |               --guestmodules=/home/ymzhang/guest/modules top
>   |
>   |
>   |   is very obvious even with a single guest. Now multiply that by more guests ...
>   |
>
> For example we want 'perf kvm top' to do something useful by default: it
> should find the first guest running and it should report its profile.
>
> The tool shouldnt have to guess about where the guests are, what their
> namespaces is and how to talk to them. We also want easy symbolic access to
> guest, for example:
>
>    perf kvm -g OpenSuse-2 record sleep 1
>    

Two things are needed.  The first thing needed is to be able to 
enumerate running guests and identify a symbolic name.  I have a patch 
for this and it'll be posted this week or so.  perf will need to have a 
QMP client and it will need to look in ${HOME}/.qemu/qmp/ to sockets to 
connect to.

This is too much to expect from a client and we've got a GSoC idea 
posted to make a nice library for tools to use to simplify this.

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

>   - Guest-transparent VFS integration into the host, to recover symbols and
>     debug info in binaries, etc.
>    

The way I'd like to see this implemented is a guest userspace daemon.  I 
think having the guest userspace daemon be something that can be updated 
by the host is reasonable.

In terms of exposing that on the host, my preferred approach is QMP.  
I'd be happy with a QMP command that is essentially, 
guest_fs_read(filename) and guest_fd_readdir(path).

If desired, one could implement a fuse filesystem that interacted with 
all local qemu instances to expose this on the host.  There's a lot of 
ugly things about fuse though so I think sticking to QMP is best 
(particularly with respect to root access of a fuse filesystem).

With just those couple things in place, perf should be able to do 
exactly what you want it to do.

Regards,

Anthony Liguroi

> There were a few responses to that but none really addressed those problems -
> they mostly tried to re-define the problem and suggested that i was wrong to
> want such capabilities and suggested various inferior approaches instead. See
> the thread for the details - i think i covered every technical suggestion that
> was made.
>
> So we are still at an impasse as far as i can see. If i overlooked some
> suggestion that addresses these problems then please let me know ...
>
> Thanks,
>
> 	Ingo
>