qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in li


From: Luiz Capitulino
Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
Date: Wed, 24 Mar 2010 18:33:05 -0300

On Wed, 24 Mar 2010 21:54:09 +0100
Alexander Graf <address@hidden> wrote:

> 
> On 24.03.2010, at 21:32, Anthony Liguori wrote:
> 
> > On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
> >> On Wed, 24 Mar 2010 21:49:45 +0200
> >> Avi Kivity<address@hidden>  wrote:
> >> 
> >>   
> >>> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
> >>>     
> >>>> On Wed, 24 Mar 2010 12:42:16 +0200
> >>>> Avi Kivity<address@hidden>   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.
> > 
> >>  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.  
> > 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.
> 
> The feature problem isn't the only one. It's also about ease of use. I 
> personally find the qemu command line easier to use than anything 
> libvirt-derived.

 Because your a developer and it does make sense to have a good CLI,
on the other hand we also have use cases for a GUI bundled in QEMU
and libvirt-derived things, which know how to deal with several
VMs and integrates well with lots of other things.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]