[libvirt] [PATCH] qemu: Transfer inactive XML among cookie
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
>> 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.
/* 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.
More information about the libvir-list