Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: [PATCH 11/12] md: convert cpu notifier to return encapsulate errno value
Next: [GIT PULL] vhost-net fixes for issues in 2.6.34-rc1
From: Daniel P. Berrange on 22 Mar 2010 15:40 On Mon, Mar 22, 2010 at 02:15:35PM -0500, Anthony Liguori wrote: > On 03/22/2010 12:55 PM, Avi Kivity 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. > > We're stuck in a rut with libvirt and I think a lot of the > dissatisfaction with qemu is rooted in that. It's not libvirt that's > the probably, but the relationship between qemu and libvirt. > > We add a feature to qemu and maybe after six month it gets exposed by > libvirt. Release time lines of the two projects complicate the > situation further. People that write GUIs are limited by libvirt > because that's what they're told to use and when they need something > simple, they're presented with first getting that feature implemented in > qemu, then plumbed through libvirt. That is somewhat unfair as a blanket statement! While some features have had a long time delay & others are not supported at all, in many cases we have had zero delay. We have been supporting QMP, qdev, vhost-net since before the patches for those features were even merged in QEMU GIT! It varies depending on how closely QEMU & libvirt people have been working together on a feature, and on how strongly end users are demanding the features. > It wouldn't be so bad if libvirt was basically a passthrough interface > to qemu but it tries to model everything in a generic way which is more > or less doomed to fail when you're adding lots of new features (as we are). > > The list of things that libvirt doesn't support and won't any time soon > is staggering. As previously discussed, we want to improve both the set of features supported, and make it much easier to support new features promptly. The QMP & qdev stuff has been a very good step forward in making it easier to support QEMU management. There have been a proposals from several people, yourself included, on how to improve libvirt's support for the full range of QEMU features. We're committed to looking at this and figuring out which proposals are practical to support, so we can improve QEMU & libvirt interaction for everyone. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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: Alexander Graf on 22 Mar 2010 15:40 On 22.03.2010, at 20:31, Daniel P. Berrange wrote: > On Mon, Mar 22, 2010 at 02:15:35PM -0500, Anthony Liguori wrote: >> On 03/22/2010 12:55 PM, Avi Kivity 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. >> >> We're stuck in a rut with libvirt and I think a lot of the >> dissatisfaction with qemu is rooted in that. It's not libvirt that's >> the probably, but the relationship between qemu and libvirt. >> >> We add a feature to qemu and maybe after six month it gets exposed by >> libvirt. Release time lines of the two projects complicate the >> situation further. People that write GUIs are limited by libvirt >> because that's what they're told to use and when they need something >> simple, they're presented with first getting that feature implemented in >> qemu, then plumbed through libvirt. > > That is somewhat unfair as a blanket statement! > > While some features have had a long time delay & others are not supported > at all, in many cases we have had zero delay. We have been supporting QMP, > qdev, vhost-net since before the patches for those features were even merged > in QEMU GIT! It varies depending on how closely QEMU & libvirt people have > been working together on a feature, and on how strongly end users are demanding > the features. Yes. I think the point was that every layer in between brings potential slowdown and loss of features. Hopefully this will go away with QMP. By then people can decide if they want to be hypervisor agnostic (libvirt) or tightly coupled with qemu (QMP). The best of both worlds would of course be a QMP pass-through in libvirt. No idea if that's easily possible. Either way, things are improving. What people see at the end is virt-manager though. And if you compare if feature-wise as well as looks-wise vbox is simply superior. Several features lacking in lower layers too (pv graphics, always working absolute pointers, clipboard sharing, ...). That said it doesn't mean we should resign. It means we know which areas to work on :-). And we know that our problem is not the kernel/userspace interface, but the qemu and above interfaces. Alex-- 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: Alexander Graf on 22 Mar 2010 16:00 On 22.03.2010, at 20:54, Ingo Molnar wrote: > > * Alexander Graf <agraf(a)suse.de> wrote: > >> Yes. I think the point was that every layer in between brings potential >> slowdown and loss of features. > > Exactly. The more 'fragmented' a project is into sub-projects, without a > single, unified, functional reference implementation in the center of it, the > longer it takes to fix 'unsexy' problems like trivial usability bugs. I agree to that part. As previously stated there are few people working on qemu that would go and implement higher level things though. So some solution is needed there. > Furthermore, another negative effect is that many times features are > implemented not in their technically best way, but in a way to keep them local > to the project that originates them. This is done to keep deployment latencies > and general contribution overhead down to a minimum. The moment you have to > work with yet another project, the overhead adds up. I disagree there. Keeping things local and self-contained has been the UNIX secret. It works really well as long as the boundaries are well defined. The problem we're facing is that we're simply lacking an active GUI / desktop user development community. We have desktop users, but nobody feels like tackling the issue of doing a great GUI project while talking to qemu-devel about his needs. > So developers rather go for the quicker (yet inferior) hack within the > sub-project they have best access to. Well - not necessarily hacks. It's more about project boundaries. Nothing is bad about that. You wouldn't want "ls" implemented in the Linux kernel either, right? :-) Alex-- 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: Daniel P. Berrange on 22 Mar 2010 17:00 On Tue, Mar 23, 2010 at 03:00:28AM +0700, Antoine Martin wrote: > On 03/23/2010 02:15 AM, Anthony Liguori wrote: > >On 03/22/2010 12:55 PM, Avi Kivity 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. > > > >We're stuck in a rut with libvirt and I think a lot of the > >dissatisfaction with qemu is rooted in that. It's not libvirt that's > >the probably, but the relationship between qemu and libvirt. > +1 > The obvious reason why so many people still use shell scripts rather > than libvirt is because if it just doesn't provide what they need. > Every time I've looked at it (and I've been looking for a better > solution for many years), it seems that it would have provided most of > the things I needed, but the remaining bits were unsolvable. If you happen to remember what missing features prevented you choosing libvirt, that would be invaluable information for us, to see if there are quick wins that will help out. We got very useful feedback when recently asking people this same question http://rwmj.wordpress.com/2010/01/07/quick-quiz-what-stops-you-from-using-libvirt/ Allowing arbitrary passthrough of QEMU commands/args will solve some of these issues, but certainly far from solving all of them. eg guest cut+ paste, host side control of guest screen resolution, easier x509/TLS configuration for remote management, soft reboot, Windows desktop support for virt-manager, host network interface management/setup, etc Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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: Olivier Galibert on 23 Mar 2010 05:50
On Mon, Mar 22, 2010 at 03:54:37PM +0100, Ingo Molnar wrote: > Yes, i thought Qemu would be a prime candidate to be the baseline for > tools/kvm/, but i guess that has become socially impossible now after this > flamewar. It's not a big problem in the big scheme of things: tools/kvm/ is > best grown up from a small towards larger size anyway ... I'm curious, where would you put the limit? Let's imagine a tools/kvm appears, be it qemu or not, that's outside the scope of my question. Would you put the legacy PC bios in there (seabios I guess)? The EFI bios? The windows-compiled paravirtual drivers? The Xorg paravirtual DDX ? Mesa (which includes the pv gallium drivers)? The libvirt-equivalent? The GUI? That's not a rhetorical question btw, I really wonder where the limit should be. OG. -- 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/ |