[Top][All Lists]
[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
>>
- Re: [Qemu-devel] KVM call minutes for Oct 19, (continued)
- Re: [Qemu-devel] KVM call minutes for Oct 19, Daniel P. Berrange, 2010/10/21
- Re: [Qemu-devel] KVM call minutes for Oct 19, Anthony Liguori, 2010/10/21
- Re: [Qemu-devel] KVM call minutes for Oct 19, Andrew Beekhof, 2010/10/21
- Re: [Qemu-devel] KVM call minutes for Oct 19, Anthony Liguori, 2010/10/21
- Re: [Qemu-devel] KVM call minutes for Oct 19, Chris Wright, 2010/10/21
- Re: [Qemu-devel] KVM call minutes for Oct 19, Andrew Beekhof, 2010/10/21
Re: [Qemu-devel] KVM call minutes for Oct 19, Anthony Liguori, 2010/10/20
- Re: [Qemu-devel] KVM call minutes for Oct 19, Daniel P. Berrange, 2010/10/20
- Re: [Qemu-devel] KVM call minutes for Oct 19, Anthony Liguori, 2010/10/20
- Re: [Qemu-devel] KVM call minutes for Oct 19, Dor Laor, 2010/10/20
- Re: [Qemu-devel] KVM call minutes for Oct 19,
Alexander Graf <=
- Re: [Qemu-devel] KVM call minutes for Oct 19, Paolo Bonzini, 2010/10/21
- Re: [Qemu-devel] KVM call minutes for Oct 19, Anthony Liguori, 2010/10/21
- Re: [Qemu-devel] KVM call minutes for Oct 19, Dor Laor, 2010/10/21
- Re: [Qemu-devel] KVM call minutes for Oct 19, Chris Wright, 2010/10/22
- Re: [Qemu-devel] KVM call minutes for Oct 19, Anthony Liguori, 2010/10/22
- Re: [Qemu-devel] KVM call minutes for Oct 19, Chris Wright, 2010/10/22
- Re: [Qemu-devel] KVM call minutes for Oct 19, Anthony Liguori, 2010/10/22
- Re: [Qemu-devel] KVM call minutes for Oct 19, Chris Wright, 2010/10/22