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

[Alexander Graf]

On 24.03.2010, at 22:33, Luiz Capitulino wrote:

> 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.

Oh I certainly would use a GUI if it was easy to use for me.

Imagine we had a full machine description configuration, similar to a .vmx 
file. A GUI would simply use that. Whenever I add a feature or want to test 
something out, I'd use that .vmx file with the GUI and everything would be 
great.

In fact, I'd prefer that over remembering weird command line options for qemu. 
And you can always just expose something like the monitor interface using the 
GUI.


Alex