KVM, QEMU, and kernel project management [LWN.net]

KVM, QEMU, and kernel project management

Posted Mar 24, 2010 6:48 UTC (Wed) by jcm (subscriber, #18262)
Parent article: KVM, QEMU, and kernel project management

No offense intended toward Ingo, but there really isn't a huge insurmountable technical challenge here. Both Avi and Daniel have suggested perfectly valid technology fixes (that just happen to not be exactly what Ingo asked for, but are not invalid either):

*). A symbol server in guests exporting the data you want/need.
*). libguestfs if you really want to violate a running guest.

Personally, I like perf, but it is just a tool. It's a nice tool and it might be nice to poke at a running guest in some situations (I consider already that there is too much coupling here for safety and would rather the kernel not be doing that directly) but there are plenty of ways to get at the required data and process it without merging whole other projects into the kernel or requiring the kernel to re-implement libvirt features.

I'd rather the kernel had nice stable versioned interfaces with some tools in tree, and others out of tree, and that that not be a big deal. The issue of developers not paying attention between userspace and kernel is a cultural divide that needs fixing - sites like LWN do a good job at educating about ongoing work - and that can be done by simply poking at something of interest without changing any development process.

Jon.

to post comments

KVM, QEMU, and kernel project management

Posted Mar 26, 2010 9:58 UTC (Fri) by mingo (subscriber, #31122) [Link] (2 responses)

  No offense intended toward Ingo, but there really isn't a huge
  insurmountable technical challenge here. Both Avi and Daniel have
  suggested perfectly valid technology fixes (that just happen to
  not be exactly what Ingo asked for, but are not invalid either):

(No offense taken at all!)

Even ignoring my opinion that those solutions are inadequate, multiple people on the list expressed their opinion that it's inadequate.

One of the concerns expressed against Avi's suggestion was that having to modify the guest user-space to export data creates a lot of deployment burden and is also guest-visible (for example if an UDP port is needed then networking is needed in the guest, plus it takes away a slot from the guest UDP port space).

Such kind of burden, even if it's technically equivalent otherwise, can make or break the viability of an instrumentation solution. (instrumentation is all about being able to get its stuff with minimal effect on the observed system. The whole point of 'perf kvm' is to observe the guest externally.)

Also, allowing to unify/mount the guest VFS into the host VFS was one out of two main areas of contention. The other one was the lack of kernel-provided enumeration for vcpu contexts.

The solution offered was to enumerate voluntarily in user-space via a ~/.qemu/ socket mechanism - but that approach has a number of problems beyond being tied to Qemu. A profiling/RAS tool wants to be able to discover and connect to any KVM context, not just Qemu enumerated ones.

It's as if 'ps' was implemented not by asking the kernel about what tasks are running in the system - but each app voluntarily registering themselves in some /var registry. Such schemes are fundamentally fragile and instrumentation code shies away from that for good reasons.

Not only was there disagreement, our concerns weren't even accepted as valid concerns and were brushed aside and labelled 'red herring'. It's not possible to make progress in such an environment of discussion.

Thanks, Ingo

KVM, QEMU, and kernel project management

Posted Mar 31, 2010 13:36 UTC (Wed) by gdamjan (subscriber, #33634) [Link] (1 responses)

But you still need a special kernel in the guest, right? - a Linux kernel even.

So,
and considering there's a standardized host-guest communication channel now (virtio-ring I think), can't the perf support be in the guest kernel?

KVM, QEMU, and kernel project management

Posted Apr 1, 2010 20:57 UTC (Thu) by oak (guest, #2786) [Link]

What about other tracing solutions?

For example hypervisor & host tracing was presented for LTT already in 2008:
http://lttng.org/files/papers/desnoyers-ols2008.pdf

The LTTV UI for LTT trace data has support for merging different (GB sized) traces based on the trace clock/timestamps. Good UI is crucial for making sense of the data, especially if one has several guests running at the same time.