KVM, QEMU, and kernel project management

KVM, QEMU, and kernel project management

Posted Mar 26, 2010 9:58 UTC (Fri) by mingo (subscriber, #31122)
In reply to: KVM, QEMU, and kernel project management by jcm
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):

(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

---

(Log in to post comments)