Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Anthony Liguori on 22 Mar 2010 18:10 On 03/22/2010 02:47 PM, Avi Kivity wrote: > On 03/22/2010 09:27 PM, Ingo Molnar wrote: >> >>> If your position basically boils down to, we can't trust userspace >>> and we can always trust the kernel, I want to eliminate any >>> userspace path, then I can't really help you out. >> Why would you want to 'help me out'? I can tell a good solution from >> a bad one >> just fine. > > You are basically making a kernel implementation a requirement, > instead of something that follows from the requirement. > >> You should instead read the long list of disadvantages above, invert >> them and >> list then as advantages for the kernel-based vcpu enumeration >> solution, apply >> common sense and go admit to yourself that indeed in this situation a >> kernel >> provided enumeration of vcpu contexts is the most robust solution. > > Having qemu enumerate guests one way or another is not a good idea IMO > since it is focused on one guest and doesn't have a system-wide entity. There always needs to be a system wide entity. There are two ways to enumerate instances from that system wide entity. You can centralize the creation of instances and there by maintain an list of current instances. You can also allow instances to be created in a decentralized manner and provide a standard mechanism for instances to register themselves with the system wide entity. IOW, it's the difference between asking libvirtd to exec(qemu) vs allowing a user to exec(qemu) and having qemu connect to a well known unix domain socket for libvirt to tell libvirtd that it exists. The later approach has a number of advantages. libvirt already supports both models. The former is the '/system' uri and the later is the '/session' uri. What I'm proposing, is to use the host file system as the system wide entity instead of libvirtd. libvirtd can monitor the host file system to participate in these activities but ultimately, moving this functionality out of libvirtd means that it becomes the standard mechanism for all qemu instances regardless of how they're launched. Regards, Anthony Liguori > A userspace system-wide entity will work just as well as kernel > implementation, without its disadvantages. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 23 Mar 2010 05:10 On 03/23/2010 12:06 AM, Anthony Liguori wrote: >> Having qemu enumerate guests one way or another is not a good idea >> IMO since it is focused on one guest and doesn't have a system-wide >> entity. > > > There always needs to be a system wide entity. There are two ways to > enumerate instances from that system wide entity. You can centralize > the creation of instances and there by maintain an list of current > instances. You can also allow instances to be created in a > decentralized manner and provide a standard mechanism for instances to > register themselves with the system wide entity. > > IOW, it's the difference between asking libvirtd to exec(qemu) vs > allowing a user to exec(qemu) and having qemu connect to a well known > unix domain socket for libvirt to tell libvirtd that it exists. > > The later approach has a number of advantages. libvirt already > supports both models. The former is the '/system' uri and the later > is the '/session' uri. > > What I'm proposing, is to use the host file system as the system wide > entity instead of libvirtd. libvirtd can monitor the host file system > to participate in these activities but ultimately, moving this > functionality out of libvirtd means that it becomes the standard > mechanism for all qemu instances regardless of how they're launched. I don't like dropping sockets into the host filesystem, especially as they won't be cleaned up on abnormal exit. I also think this breaks our 'mechanism, not policy' policy. Someone may want to do something weird with qemu that doesn't work well with this. We could allow starting monitors from the global configuration file, so a distribution can do this if it wants, but I don't think we should do this ourselves by default. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kevin Wolf on 23 Mar 2010 06:20 Am 22.03.2010 23:06, schrieb Anthony Liguori: > On 03/22/2010 02:47 PM, Avi Kivity wrote: >> Having qemu enumerate guests one way or another is not a good idea IMO >> since it is focused on one guest and doesn't have a system-wide entity. > > There always needs to be a system wide entity. There are two ways to > enumerate instances from that system wide entity. You can centralize > the creation of instances and there by maintain an list of current > instances. You can also allow instances to be created in a > decentralized manner and provide a standard mechanism for instances to > register themselves with the system wide entity. > > IOW, it's the difference between asking libvirtd to exec(qemu) vs > allowing a user to exec(qemu) and having qemu connect to a well known > unix domain socket for libvirt to tell libvirtd that it exists. I think the latter is exactly what I would want for myself. I do see the advantages of having a central instance, but I really don't want to bother with libvirt configuration files or even GUIs just to get an ad-hoc VM up when I can simply run "qemu -hda hd.img -m 1024". Let alone that I usually want to have full control over qemu, including monitor access and small details available as command line options. I know that I'm not the average user with these requirements, but still I am one user and do have these requirements. If I could just install libvirt, continue using qemu as I always did and libvirt picked my VMs up for things like global enumeration, that would be more or less the optimal thing for me. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Antoine Martin on 23 Mar 2010 06:30 On 03/23/2010 05:13 PM, Kevin Wolf wrote: > Am 22.03.2010 23:06, schrieb Anthony Liguori: > >> On 03/22/2010 02:47 PM, Avi Kivity wrote: >> >>> Having qemu enumerate guests one way or another is not a good idea IMO >>> since it is focused on one guest and doesn't have a system-wide entity. >>> >> There always needs to be a system wide entity. There are two ways to >> enumerate instances from that system wide entity. You can centralize >> the creation of instances and there by maintain an list of current >> instances. You can also allow instances to be created in a >> decentralized manner and provide a standard mechanism for instances to >> register themselves with the system wide entity. >> >> IOW, it's the difference between asking libvirtd to exec(qemu) vs >> allowing a user to exec(qemu) and having qemu connect to a well known >> unix domain socket for libvirt to tell libvirtd that it exists. >> > I think the latter is exactly what I would want for myself. I do see the > advantages of having a central instance, but I really don't want to > bother with libvirt configuration files or even GUIs just to get an > ad-hoc VM up when I can simply run "qemu -hda hd.img -m 1024". Let alone > that I usually want to have full control over qemu, including monitor > access and small details available as command line options. > > I know that I'm not the average user with these requirements, but still > I am one user and do have these requirements. If I could just install > libvirt, continue using qemu as I always did and libvirt picked my VMs > up for things like global enumeration, that would be more or less the > optimal thing for me. > +1 And it would also make it more likely that users like us would convert to libvirt in the long run, by providing an easy and integrated transition path. I've had another look at libvirt, and one of the things that is holding me back is the cost of moving existing scripts to libvirt. If it could just pick up what I have (at least in part), then I don't have to. Antoine > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bernd Petrovitsch on 23 Mar 2010 06:50
On Mon, 2010-03-22 at 21:21 +0100, Ingo Molnar wrote: [...] > Have you made thoughts about why that might be so? Yes. Forword: I assume with "GUI" you mean "a user interface for the classical desktop user with next to no interest in learning details or basics". That doesn't mean the classical desktop user is silly, stupid or otherwise handicapped - it's just the lack of interest and/or time. > I think it's because of what i outlined above - that you are trying to apply > the "UNIX secret" to GUIs - and that is a mistake. No, it's the very same mechanism. But you just have to start at the correct point. In the kernel/device driver world, you start at the device. And in the GUI world, you better start at the GUI (and not some kernel API, library API, GUI tool or toolchains or anywhere else). > A good GUI is almost at the _exact opposite spectrum_ of good command-line > tool: tightly integrated, with 'layering violations' designed into it all over > the place: > > look i can paste the text from an editor straight into a firefox form. I > didnt go through any hiearchy of layers, i just took the shortest path > between the apps! > > In other words: in a GUI the output controls the design, for command-line ACK, because you to make the GUI understandable to the intended users. If that means "hiding 90% of all possibilities and features", you just hide them. Of course, the user of such an UI is quite limited doesn't use much of the functionality - because s/he can't access it through the GUI - (but presenting 100% - or even 40% - doesn't help either as s/he won't understand it anyways). > tools the design controls the output. ACK, because the user in this case (which is most of the time a developer, sys-admin, or similar techie) *wants* an 1:1 picture of the underlying model because s/he already *knows* the underlying model (and is willing and able to adapt the own workflow to the underlying models). > It is no wonder Unix always had its problems with creating good GUIs that are ACK. The clichee-Unix-person doesn't come from the "GUI world". So most of them are "trained" and used to look what's there and improve on it. > efficient to humans. A good GUI works like the human brain, and the human > brain does not mind 'layering violations' when that gets it a more efficient > result. If this is the case, the layering/structure/design of the GUI is (very) badly defined/chosen (for whatever reason). [ Most probably because some seasoned software developer designed the GUI-app *without* designing (and testing!) the GUI (or more to the point: the look - how does it look like - and feel - how does it behave, what are the possible workflows, ... - of it) first. ] Bernd -- Bernd Petrovitsch Email : bernd(a)petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |