Re: [libvirt] [PATCH] qemu: Transfer inactive XML among cookie
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)*/
const VIR_NET_MESSAGE_HEADER_MAX = 24;
/* Size of message payload */
const VIR_NET_MESSAGE_PAYLOAD_MAX = 262120;
/* Size of message length field. Not counted in VIR_NET_MESSAGE_MAX */
const VIR_NET_MESSAGE_LEN_MAX = 4;
/* 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.
*/
const VIR_NET_MESSAGE_STRING_MAX = 65536;
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.
Michal