On 03/22/2010 09:20 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by
Anthony. There's numerous ways that this can break:
I don't like it either. We have libvirt for enumerating guests.
Which has pretty much the same problems to the ${HOME}/.qemu/qmp/ solution,
obviously.
It doesn't follow. The libvirt daemon could/should own guests from all
users. I don't know if it does so now, but nothing is preventing it
technically.
- 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.
- it doesn't work with nfs.
So out of a list of 4 disadvantages your reply is that you agree with 3?
I agree with 1-3, disagree with 4, and add 5. Yes.
- 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.
If qemu doesn't reply, your guest is dead anyway.
Erm, but i'm talking about a dead tool here. There's a world of a difference
between 'kvm top' not showing new entries (because the guest is dead), and
'perf kvm top' hanging due to Qemu hanging.
If qemu hangs, the guest hangs a few milliseconds later.
So it's essentially 4 our of 4. Yet your reply isnt "Ingo you are right" but
"hey, too bad" ?
My reply is "you are right" (phrased earlier as "I don't like it either"
meaning I agree with your dislike). One of your criticisms was invalid,
IMO, and I pointed it out.
Really, for such reasons user-space is pretty poor at doing system-wide
enumeration and resource management. Microkernels lost for a reason.
Take a look at your desktop, userspace is doing all of that everywhere, from
enumerating users and groups, to deciding how your disks are named. The
kernel only provides the bare facilities.
We dont do that for robust system instrumentation, for heaven's sake!
If qemu fails, you lose your guest. If libvirt forgets about a guest,
you can't do anything with it any more. These are more serious problems
than 'perf kvm' not working. Qemu and libvirt have to be robust anyway,
we can rely on them. Like we have to rely on init, X, sshd, and a
zillion other critical tools.
By your argument it would be perfectly fine to implement /proc purely via
user-space, correct?
I would have preferred /proc to be implemented via syscalls called
directly from tools, and good tools written to expose the information in
it. When computers were slower 'top' would spend tons of time opening
and closing all those tiny files and parsing them. Of course the kernel
needs to provide the information.
You are committing several grave design mistakes here.
I am committing on the shoulders of giants.
Really, this is getting outright ridiculous. You agree with me that Anothony
suggested a technically inferior solution, yet you even seem to be proud of it
and are joking about it?
The bit above this was:
Really, for such reasons user-space is pretty poor at doing system-wide
enumeration and resource management. Microkernels lost for a reason.
In every Linux system userspace is doing or proxying much of the
enumeration and resource management. So if enumerating guests in
userspace is a mistake, then I am not alone in making it.
And _you_ are complaining about lkml-style hard-talk discussions?
There is a difference between joking and insulting people. I enjoy
jokes but I dislike being insulted.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
