On 04/27/2012 07:22 AM, Michal Privoznik wrote: > Since we are allocating RPC buffer dynamically, we can increase limits > for max. size of RPC message and RPC string. This is needed to cover > some corner cases where libvirt is run on such huge machines that their > capabilities XML is 4 times bigger than our current limit. This leaves > users with inability to even connect. > --- > src/remote/remote_protocol.x | 2 +- > src/rpc/virnetprotocol.x | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) >
> +++ b/src/remote/remote_protocol.x
> @@ -65,7 +65,7 @@
> * 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 REMOTE_STRING_MAX = 65536;
> +const REMOTE_STRING_MAX = 1048576;
16x increase. Are we ever going to wish for more than a megabyte?
Should we be thinking about a handshaking between client and server,
where they negotiate up front the largest message either is willing to
receive (and where the limits may be asymmetrical)?
> +++ b/src/rpc/virnetprotocol.x
> @@ -45,13 +45,13 @@
> /*----- Data types. -----*/
>
> /* Maximum total message size (serialised). */
> -const VIR_NET_MESSAGE_MAX = 262144;
> +const VIR_NET_MESSAGE_MAX = 4194304;
So a message remains capped at 4 max-size strings within a struct; and
in the general case where you aren't using max-size strings, you have
more room for other elements in your message.
Aren't there other limits we should be increasing at the same time? I
can think of:
REMOTE_DOMAIN_NAME_LIST_MAX (having more than 1024 guests defined,
although not necessarily all running, is starting to be feasible)
REMOTE_{NETWORK,INTERFACE}_NAME_LIST_MAX (256 is even more restricted,
given the ability of modern cards to have multiple virtual interfaces)
REMOTE_STORAGE_POOL_NAME_LIST_MAX (one pool per VM is a reasonable
layout, which means it should be at least 1024 to match
REMOTE_DOMAIN_NAME_LIST_MAX)
REMOTE_STORAGE_VOL_NAME_LIST_MAX (some users like directories with lots
of files; 1024 seems small)
REMOTE_NODE_DEVICE_CAPS_LIST_MAX (16k is feeling small for some of
today's super-beefy machines with lots of cpus)
REMOTE_DOMAIN_{BLOCK,MEMORY}_PEEK_BUFFER_MAX (64k may still be
reasonable, but why not take advantage of the larger limits for peeking
more memory in fewer transactions)
Any others?
--
Eric Blake [email protected] +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
