[libvirt] [PATCH] qemu: Transfer inactive XML among cookie

Michal Privoznik mprivozn at redhat.com
Thu Sep 15 14:38:58 UTC 2011

On 15.09.2011 16:16, Eric Blake wrote:
> On 09/15/2011 08:04 AM, Michal Privoznik wrote:
>> If a domain has inactive XML we want to transfer it to destination
>> when migrating with VIR_MIGRATE_PERSIST_DEST. In order to harm
>> the migration protocol as least as possible, a optional cookie was
>> chosen.
>> ---
>>   src/qemu/qemu_migration.c |   91
>> ++++++++++++++++++++++++++++++++++++++++----
>>   1 files changed, 82 insertions(+), 9 deletions(-)
> I haven't looked at the patch closely, but think you are on the right
> track.  At the high level, though, I'm wondering if our cookie is large
> enough - what limits does our RPC protocol already provide on the size
> of domain xml going over the wire?  We're basically doubling that size,
> by sending both a full domain xml and a cookie containing another domain
> xml.  For example, if the current RPC limit is 64k of data on one
> transaction, and we have a 33k domain xml, then we will fail to migrate
> unless we also bump RPC limits.  But since I don't know the current
> limits on RPC sizes, I may be worrying about nothing.

>From src/rpc/virnetprotocol.x:

/* Maximum total message size (serialised). */
const VIR_NET_MESSAGE_MAX = 262144;

/* Size of struct virNetMessageHeader (serialised)*/

/* Size of message payload */

/* Size of message length field. Not counted in VIR_NET_MESSAGE_MAX */

/* Length of long, but not unbounded, strings.
 * This is an arbitrary limit designed to stop the decoder from trying
 * to allocate unbounded amounts of memory when fed with a bad message.

So the max size of string is 65K. BUT, because we don't sent 2 XML in
one RPC I don't think we are gonna hit that limit soon. My patch sent
domain XML among with cookie which is small, not 2 XMLs at the same
time. Right now, at the finish phase - which is the place where I send
domain xml - the size of cookie is 222B + sizeof(domain name).

Therefore I think there is no need to increase the bound for string.


More information about the libvir-list mailing list