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 Liguori
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
