* Avi Kivity <a...@redhat.com> wrote:
> >>> - 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.
> >>
> >> Usually 'layering violation' is trotted out at such suggestions.
> >> [...]
> >
> > That's weird, how can a feature request be a 'layering violation'?
>
> The 'something trustable and kernel-provided'. The kernel knows nothing
> about guest names.
The kernel certainly knows about other resources such as task names or network
interface names or tracepoint names. This is kernel design 101.
> > If something that users find straightforward and usable is a layering
> > violation to you (such as easily being able to access their own files on
> > the host as well ...) then i think you need to revisit the definition of
> > that term instead of trying to fix the user.
>
> Here is the explanation, you left it quoted:
>
> >> [...] I don't like using the term, because sometimes the layers are
> >> incorrect and need to be violated. But it should be done explicitly, not
> >> as a shortcut for a minor feature (and profiling is a minor feature, most
> >> users will never use it, especially guest-from-host).
> >>
> >> The fact is we have well defined layers today, kvm virtualizes the cpu
> >> and memory, qemu emulates devices for a single guest, libvirt manages
> >> guests. We break this sometimes but there has to be a good reason. So
> >> perf needs to talk to libvirt if it wants names. Could be done via
> >> linking, or can be done using a pluging libvirt drops into perf.
This is really just the much-discredited microkernel approach for keeping
global enumeration data that should be kept by the kernel ...
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by Anthony.
There's numerous ways that this can break:
- Those special files can get corrupted, mis-setup, get out of sync, or can
be hard to discover.
- The ${HOME}/.qemu/qmp/ solution suggested by Anthony has a very obvious
design flaw: it is per user. When i'm root i'd like to query _all_ current
guest images, not just the ones started by root. A system might not even
have a notion of '${HOME}'.
- Apps might start KVM vcpu instances without adhering to the
${HOME}/.qemu/qmp/ access method.
- There is no guarantee for the Qemu process to reply to a request - while
the kernel can always guarantee an enumeration result. I dont want 'perf
kvm' to hang or misbehave just because Qemu has hung.
Really, for such reasons user-space is pretty poor at doing system-wide
enumeration and resource management. Microkernels lost for a reason.
You are committing several grave design mistakes here.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
