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 eblake@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list