Am 21.10.2010 um 00:46 schrieb Dor Laor <dlaor@xxxxxxxxxx>: > 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 >> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
