On Wed, 24 Mar 2010 15:32:42 -0500 Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: > On 03/24/2010 03:12 PM, Luiz Capitulino wrote: > > On Wed, 24 Mar 2010 21:49:45 +0200 > > Avi Kivity<avi@xxxxxxxxxx> wrote: > > > > > >> On 03/24/2010 06:42 PM, Luiz Capitulino wrote: > >> > >>> On Wed, 24 Mar 2010 12:42:16 +0200 > >>> Avi Kivity<avi@xxxxxxxxxx> wrote: > >>> > >>> > >>> > >>>> So, at best qemud is a toy for people who are annoyed by libvirt. > >>>> > >>>> > >>> Is the reason for doing this in qemu because libvirt is annoying? > >>> > >> Mostly. > >> > >> > >>> I don't see > >>> how adding yet another layer/daemon is going to improve ours and user's life > >>> (the same applies for libqemu). > >>> > >>> > >> libvirt becomes optional. > >> > > I think it should only be optional if all you want is to run a single VM > > in this case what seems to be missing on our side is a _real_ GUI, bundled > > with QEMU potentially written in a high-level language. > > > > That's a separate problem. I see it as a related problem, because what seems to be under discussion is the quality of our interfaces with humans and tools. Also, when we were discussing the usuability problems I remember that you *WARNING: I might be wrong here, please correct me if so* you said that you don't push users to libvirt because it's out of sync with our features. The point is that, even if this true and even if we solve that, I don't think it will solve the problem of a good experience for a 'single VM user', because libvirt is more than that and people will likely be annoyed as much as they are today. I believe this problem is up to us to solve. > > Then we make virt-manager optional and this is good because we can sync > > features way faster and we don't have to care about _managing_ several > > VMs, our world in terms of usability and maintainability is about one VM. > > > > IMVHO, everything else should be done by third-party tools like libvirt, > > we just provide the means for it. > > > > We need to have a common management interface for third party tools. QMP? :-) > libvirt cannot be that today because of the fact that it doesn't support > all of our features. What we need to figure out is how we can work with > the libvirt team to fix this. Agreed. > So far, a libqemu.so with a flexible transport that could be used > directly by a libvirt user (ala cairo/gdk type interactions) seems like > the best solution to me. I tend to disagree. First, I think we should invest our time and effort on the text protocol business, which is QMP. Having yet another public interface will likely split efforts a bit and will make clients' life harder (which one should I choose? What if they get out of sync?). Not to mention that I think Paul has a point, if QMP is not useful here, why do we have it in the first place (vs. a C library from the beginning)? You mentioned dynamic dispatch, but this is useful only for C clients right? If so, what C clients you expected beyond libvirt? Note that libvirt has added a new events API recently. The second most important point for me is: why do you believe that libqemu.so is going to improve things? Do you expect that libvirt will sync faster? If this is the case, I think it will be as slower as it's currently, as the problem is not the availability of interfaces, but most likely community integration. I like the idea of having a transient qemu-specific API in libvirt, as suggested by someone in this thread. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list