From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5sgp-0006Qe-B7 for qemu-devel@nongnu.org; Sat, 24 Apr 2010 23:39:27 -0400 Received: from [140.186.70.92] (port=51282 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5sgn-0006QV-LC for qemu-devel@nongnu.org; Sat, 24 Apr 2010 23:39:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5sgl-0008Ha-Gh for qemu-devel@nongnu.org; Sat, 24 Apr 2010 23:39:25 -0400 Received: from mail-yw0-f198.google.com ([209.85.211.198]:39800) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5sgl-0008HR-Bw for qemu-devel@nongnu.org; Sat, 24 Apr 2010 23:39:23 -0400 Received: by ywh36 with SMTP id 36so5170225ywh.4 for ; Sat, 24 Apr 2010 20:39:21 -0700 (PDT) Message-ID: <4BD3B965.3060205@codemonkey.ws> Date: Sat, 24 Apr 2010 22:39:17 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> <20100412122013.58894a64@redhat.com> <4BD09A3B.3090001@codemonkey.ws> <4BD1971B.7060907@redhat.com> <4BD1A543.1050004@codemonkey.ws> <4BD1ADA2.2050605@redhat.com> <4BD1E723.6070005@codemonkey.ws> <4BD2BDE0.7020907@redhat.com> In-Reply-To: <4BD2BDE0.7020907@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Libvirt , Jiri Denemark , Chris Lalancette , qemu-devel@nongnu.org, Luiz Capitulino On 04/24/2010 04:46 AM, Avi Kivity wrote: > On 04/23/2010 09:29 PM, Anthony Liguori wrote: >>> Maybe. We'll still have issues. For example, sVirt: if a QMP >>> command names a labeled resource, the non-libvirt user will have no >>> way of knowing how to label it. >> >> >> This is orthogonal to QMP and has to do strictly with how libvirt >> prepares a resource for qemu. > > > It's not orthogonal. If you allow qmp access behind libvirt's back, > it's a problem that you will have. My point was, if libvirt is just exposing raw qemu features, then it should be possible for qemu to arbitrate concurrent access. If libvirt implements features on top of qemu, then no other third party will be able to co-exist with those features without interacting with qemu. It's an impossible problem for qemu to solve (arbitrating access to state stored in a third party management app). >> 1) Allow libvirt users to access features of qemu that are not >> exposed through libvirt > > That's an artificial problem. If libvirt exposes all features, you > don't need to solve it. It won't. Otherwise, we wouldn't be having this discussion. >> >> 2) Provide a means for non-libvirt users to interact with qemu > > We have qmp. It doesn't do multiple guest management. I think it's > reasonable to have a qemud which does (and also does sVirt and the > zillion other things libvirt does) provided we remove them from > libvirt (long term). The only problem is that it's a lot of effort. It depends on what things you think are important. A lot of libvirt's complexity is based on the fact that it uses a daemon and needs to deal with the security implications of that. You don't need explicit labelling if you don't use a daemon. This is really the qemu model (as opposed to the xend model). In theory, it does support this with the session urls but they are currently second-class citizens in libvirt. The remote dispatch also adds a fair bit of complexity and at least for the use-cases I'm interested in, it's not an important feature. >> >> 3) Provide a unified and interoperable view of the world for >> non-libvirt and libvirt users > > This problem can be solved by the non-libvirt users adopting libvirt, > or the libvirt users dropping libvirt. I don't understand why we need > to add interoperability between users who choose an interoperability > library and users who don't choose an interoperability library. What I'd like to avoid is user confusion. Should a user use libvirt or libqemu? If they make a decision to use libqemu and then down the road want to use libvirt, how hard is it to switch? Fragmentation hurts the ecosystem and discourages good applications from existing. I think it's our responsibility to ensure there's a good management API that exists for qemu that we can actively recommend to our users. libvirt is very good at typical virtualization uses of qemu but qemu is much more than just that and has lots of advanced features. >> >> For (1), we all agree that the best case scenario would be for >> libvirt to support every qemu feature. I think we can also all agree >> though that this is not really practical and certainly not practical >> for developers since there is a development cost associated with >> libvirt support (to model an API appropriately). > > All except me, perhaps. > > We already have two layers of feature modeling: first, we mostly > emulate real life, not invent new features. PCI hotplug existed long > before qemu had support for it. Second, we do give some thought into > how we expose it through QMP. libvirt doesn't have to invent it > again, it only has to expose it through its lovely xml and C APIs. That's not what the libvirt community wants to do. We're very bias. We've made decisions about how features should be exposed and what features should be included. We want all of those features exposed exactly how we've implemented them because we think it's the right way. I'm not sure there's an obvious way forward unless we decide that there is going to be two ways to interact with qemu. One way is through the libvirt world-view and the other is through a more qemu centric view. The problem then becomes allowing those two models to co-exist happily together. The alternative is to get libvirt to just act as a thin layer to expose qemu features directly. But honestly, what's the point of libvirt if they did that? For the most part, the pool management is not virtualization specific and you could have libvirt provide that functionality without it knowing a thing about qemu. >> >> The new API proposed addresses (1) by allowing a user to drill down >> to the QMP context. It's a good solution IMHO and I think we all >> agree that there's an inherent risk to this that users will have to >> evaluate on a case-by-case basis. It's a good stop-gap though. > > Agree. > >> >> (2) is largely addressed by QMP and a config file. I'd like to see a >> nice C library, but I think a lot of other folks are happy with JSON >> support in higher level languages. > > I agree with them. C is a pretty bad choice for managing qemu (or > even, C is a pretty bad choice). > >> >> (3) is the place where there are still potential challenges. I think >> at the very least, our goal should be to enable conversion from (2) >> and (1) to be as easy as possible. That's why I have proposed >> implementing a C library for the JSON transport because we could >> plumb that through the new libvirt API. This would allow a user to >> very quickly port an application from QMP to libvirt. In order to do >> this, we need the libvirt API to expose a dedicated monitor because >> we'll need to be able to manipulate events and negotiate features. > > Most likely any application that talks QMP will hide the protocol > behind a function call interface anyway. > >> Beyond simple porting, there's a secondary question of having >> non-libvirt apps co-exist with libvirt apps. I think it's a good >> long term goal, but I don't think we should worry too much about it now. > > libvirt needs to either support all but the most esoteric use cases, > or to get out of the way completely. That's not where it is today or the path I think they're taking. I'm also not the person you have to convince of this. Regards, Anthony Liguori