qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Thu, 25 Jun 2009 13:09:33 -0500
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Avi Kivity wrote:
An RPC is overkill unless you also introduce things like life cycle management. Otherwise, you could never realistically interact with QEMU without a intermediary that handled life cycle management (e.g. libvirt).

QMP is an RPC implemented over a text based protocol, with ad-hoc marshalling.

I agree that you need something to reap dead qemus, but I don't think we can force libvirt on people.

QMP is an incremental improvement to the current monitor which people are consuming today. It will have a pretty immediate and high rate of return. libvirt can make use of it with probably very little change and it will immediately provide them with new features (async notifications) and better information about commands (error return values).

I have a really hard time not thinking this is the right thing to do because for relatively little churn we'll get a large return. If you just exposed the monitor as an RPC, I don't think you really get anything more useful than QMP and you force a lot more change in libvirt which hurt the adoption of this protocol.

This is exactly what happened with Xend's transition from SExpr/HTTP (custom RPC) -> XML-RPC -> XenAPI. libvirt still uses SExpr/HTTP because the cost of switching to the new way of doing things didn't warrant the return on investment.

s/libvirt/any other management tool that works today/g

Regards,

Anthony Liguori





reply via email to

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