qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call minutes for Oct 19


From: Alexander Graf
Subject: Re: [Qemu-devel] KVM call minutes for Oct 19
Date: Thu, 21 Oct 2010 03:14:55 +0200

Am 21.10.2010 um 00:46 schrieb Dor Laor <address@hidden>:

> On 10/20/2010 03:21 PM, Anthony Liguori wrote:
>> On 10/20/2010 08:19 AM, Daniel P. Berrange wrote:
>>> The thinking with Matahari is that there is significant overlap between
>>> agent requirements for a physical and virtual host, so it aims to provide
>>> an agent that works everywhere, whether virtualized or not. All that need
>>> change is the communication transport (TCP vs VirtIO Serial vs legacy
>>> serial vs some other data channel), and enable/disable certain agent
>>> services according to deployment scenario. Once you go to a more general
>>> purpose agent in this way, then it doesn't make such sense to put it all
>>> in the QEMU tree.
>> 
>> Actually, I don't think we want to have a common agent for physical and
>> virtual systems.
>> 
>> The requirements are actually very different. The virtual agent exists
>> solely to support hypervisor functionality. Not to provide general
>> purpose system management support.
> 
> True although there is much in common and there are several api for 
> hypervisor only. I think it's sensible to ask for such.

I'm not sure it's worth the inflexibility.

> 
> IMHO we can't put the complete guest agent code in qemu:
>  - There would be OS specific code like windows and windows only
>    interfaces (WMI)
>  - Agents can benefits from guest frameworks like dbus. Will we take
>    dbus into qemu or re-write it ourselves?

I don't understand the argument. We have plenty of binary blobs in qemu. Why 
not gave the guest agent be one of them, having the source in the qemu tree 
nevertheless?

> 
> I agree that some agent code for basic stuff like live snapshot sync with the 
> filesystem is small enough and worth to host within qemu.
> Maybe we do need more than one project?
> 

No, please. That's exactly what I don't want to see. The libvirt/qemu/virt-man 
split is killing us already. How is this going to become with 20 driver packs 
for the guest?

Alex

>> 



reply via email to

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