On Wed, Mar 14, 2012 at 08:42:35PM -0500, Jesse J. Cook wrote:
256 (8 bits) is insufficient for large scale deployments. 65536 (16
bits) is a
more appropriate limit and should be sufficient. You are more likely to run
into other system limitations first, such as the 31998 inode link limit on
ext3.
---
src/remote/remote_protocol.x | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
index 59774b2..58f0871 100644
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -103,7 +103,7 @@ const REMOTE_INTERFACE_NAME_LIST_MAX = 256;
const REMOTE_DEFINED_INTERFACE_NAME_LIST_MAX = 256;
/* Upper limit on lists of storage pool names. */
-const REMOTE_STORAGE_POOL_NAME_LIST_MAX = 256;
+const REMOTE_STORAGE_POOL_NAME_LIST_MAX = 65536;
/* Upper limit on lists of storage vol names. */
const REMOTE_STORAGE_VOL_NAME_LIST_MAX = 1024;
We have to think about what the compatibility implications are for
this kind of change. eg what is the behaviour when old client talks
to new server, and vica-verca. It might be fine, but I'd like someone
to enumerate the before & after behaviour in all combinations.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|