Avi Kivity wrote:
On 03/24/2010 03:53 PM, Alexander Graf wrote:The file server being a kernel module inside the guest? We want to be
The idea is to use a dedicated channel over virtio-serial. If theSomeone needs to know about the new guest to fetch its symbols. Or doHow about we add a virtio "guest file system access" device? The guest
you want that part in the kernel too?
would then expose its own file system using that device.
On the host side this would simply be a -virtioguestfs
unix:/tmp/guest.fs and you'd get a unix socket that gives you full
access to the guest file system by using commands. I envision something
like:
channel is present the file server can serve files over it.
able to serve things as early and hassle free as possible, so in this
case I agree with Ingo that a kernel module is superior.
I don't see why we need a fuse filesystem. We can of course create oneSEND: GET /proc/versionYeah, needs a fuse filesystem to populate the host namespace (kind of
RECV: Linux version 2.6.27.37-0.1-default (geeko@buildhost) (gcc version
4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2009-10-15
14:56:58 +0200
Now all we need is integration in perf to enumerate virtual machines
based on libvirt. If you want to run qemu-kvm directly, just go with
--guestfs=/tmp/guest.fs and perf could fetch all required information
automatically.
This should solve all issues while staying 100% in user space, right?
sshfs over virtio-serial).
later on. But for now all you need is a user connecting to that socket.