[libvirt] [PATCH] Increase the size of REMOTE_MIGRATE_COOKIE_MAX to REMOTE_STRING_MAX

Michal Privoznik mprivozn at redhat.com
Mon Jun 16 15:57:41 UTC 2014


On 28.05.2014 14:42, Shivaprasad G Bhat wrote:
> During guest migration, if the domain xml is bigger than 16384 which is
> easily possible for a guest with good number of disks, message encode fails
> for xdr_remote_domain_migrate_perform3_ret().
> So, Increase the COOKIE_MAX to STRING_MAX value.
>
> Signed-off-by: Shivaprasad G Bhat <shivaprasadbhat at gmail.com>
> ---
>   src/remote/remote_protocol.x |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
> index 1f9d583..ab9b83d 100644
> --- a/src/remote/remote_protocol.x
> +++ b/src/remote/remote_protocol.x
> @@ -86,7 +86,7 @@ const REMOTE_VCPUINFO_MAX = 16384;
>   const REMOTE_CPUMAPS_MAX = 8388608;
>
>   /* Upper limit on migrate cookie. */
> -const REMOTE_MIGRATE_COOKIE_MAX = 16384;
> +const REMOTE_MIGRATE_COOKIE_MAX = 4194304;
>
>   /* Upper limit on lists of networks. */
>   const REMOTE_NETWORK_LIST_MAX = 16384;
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>

I think this change is okay. I mean we have changed such size limits in 
the past and so far we haven't heard of any problems. And really, if 
you're doing old -> old migration, then it's the source that fails. If 
you're doing old -> new, then again, it's the source that fails. But 
doing new -> new is just fine. Then, one trouble might be new -> old but 
since we are checking the string limits, we're okay too.

ACK, but I'll wait a while with pushing and let others share their opinion.

Michal




More information about the libvir-list mailing list