|
From: | Dor Laor |
Subject: | Re: [Qemu-devel] KVM call minutes for Oct 19 |
Date: | Thu, 21 Oct 2010 00:46:44 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4 ThunderBrowse/3.3.2 |
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.
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 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?
Regards, Anthony LiguoriRegards, Daniel-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to address@hidden More majordomo info at http://vger.kernel.org/majordomo-info.html
[Prev in Thread] | Current Thread | [Next in Thread] |