[libvirt] [PATCH] RPC: Support up to 4096 cpus on the host and 256 in the guest
The RPC limits for cpu maps didn't allow to use libvirt on ultra big boxes. This patch increases size of the limits to support a maximum of 4096 cpus on the host with the built-in maximum of 256 cpus per guest. The full cpu map of such a system takes 128 kilobytes and the map for vcpu pinning is 512 bytes long. --- src/remote/remote_protocol.x | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x index 1ebbce7..a94e0db 100644 --- a/src/remote/remote_protocol.x +++ b/src/remote/remote_protocol.x @@ -82,13 +82,13 @@ const REMOTE_DOMAIN_ID_LIST_MAX = 16384; const REMOTE_DOMAIN_NAME_LIST_MAX = 16384; /* Upper limit on cpumap (bytes) passed to virDomainPinVcpu. */ -const REMOTE_CPUMAP_MAX = 256; +const REMOTE_CPUMAP_MAX = 512; /* Upper limit on number of info fields returned by virDomainGetVcpus. */ -const REMOTE_VCPUINFO_MAX = 2048; +const REMOTE_VCPUINFO_MAX = 4096; /* Upper limit on cpumaps (bytes) passed to virDomainGetVcpus. */ -const REMOTE_CPUMAPS_MAX = 16384; +const REMOTE_CPUMAPS_MAX = 131072; /* Upper limit on migrate cookie. */ const REMOTE_MIGRATE_COOKIE_MAX = 16384; -- 1.8.2.1
On 05/28/2013 06:35 AM, Peter Krempa wrote:
The RPC limits for cpu maps didn't allow to use libvirt on ultra big boxes. This patch increases size of the limits to support a maximum of 4096 cpus on the host with the built-in maximum of 256 cpus per guest. The full cpu map of such a system takes 128 kilobytes and the map for vcpu pinning is 512 bytes long. --- src/remote/remote_protocol.x | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
We missed rc1 - is this still worth getting into 1.0.6? I'm not opposed to the change, just questioning the timing of it. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 05/28/13 14:50, Eric Blake wrote:
On 05/28/2013 06:35 AM, Peter Krempa wrote:
The RPC limits for cpu maps didn't allow to use libvirt on ultra big boxes. This patch increases size of the limits to support a maximum of 4096 cpus on the host with the built-in maximum of 256 cpus per guest. The full cpu map of such a system takes 128 kilobytes and the map for vcpu pinning is 512 bytes long. --- src/remote/remote_protocol.x | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
We missed rc1 - is this still worth getting into 1.0.6?
I'm not opposed to the change, just questioning the timing of it.
I don't mind waiting until after the release to push this. Anyways this should be safe as we are just raising the limits and with some trickery I was able to verify that RPC is okay with transporting this amount of information this by reporting fake counts of cpus. Peter
On Tue, May 28, 2013 at 02:35:50PM +0200, Peter Krempa wrote:
The RPC limits for cpu maps didn't allow to use libvirt on ultra big boxes. This patch increases size of the limits to support a maximum of 4096 cpus on the host with the built-in maximum of 256 cpus per guest. The full cpu map of such a system takes 128 kilobytes and the map for vcpu pinning is 512 bytes long. --- src/remote/remote_protocol.x | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x index 1ebbce7..a94e0db 100644 --- a/src/remote/remote_protocol.x +++ b/src/remote/remote_protocol.x @@ -82,13 +82,13 @@ const REMOTE_DOMAIN_ID_LIST_MAX = 16384; const REMOTE_DOMAIN_NAME_LIST_MAX = 16384;
/* Upper limit on cpumap (bytes) passed to virDomainPinVcpu. */ -const REMOTE_CPUMAP_MAX = 256; +const REMOTE_CPUMAP_MAX = 512;
/* Upper limit on number of info fields returned by virDomainGetVcpus. */ -const REMOTE_VCPUINFO_MAX = 2048; +const REMOTE_VCPUINFO_MAX = 4096;
/* Upper limit on cpumaps (bytes) passed to virDomainGetVcpus. */ -const REMOTE_CPUMAPS_MAX = 16384; +const REMOTE_CPUMAPS_MAX = 131072;
/* Upper limit on migrate cookie. */ const REMOTE_MIGRATE_COOKIE_MAX = 16384;
4096 sounds large, but I can't help wondering if we should pre-empt the inevitable and go even bigger. In terms of RPC message size, we can afford to allow 16384 host CPUS and 4096 guest CPUS ? 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 :|
On 06/03/13 12:32, Daniel P. Berrange wrote:
On Tue, May 28, 2013 at 02:35:50PM +0200, Peter Krempa wrote:
The RPC limits for cpu maps didn't allow to use libvirt on ultra big boxes. This patch increases size of the limits to support a maximum of 4096 cpus on the host with the built-in maximum of 256 cpus per guest. The full cpu map of such a system takes 128 kilobytes and the map for vcpu pinning is 512 bytes long. --- src/remote/remote_protocol.x | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x index 1ebbce7..a94e0db 100644 --- a/src/remote/remote_protocol.x +++ b/src/remote/remote_protocol.x @@ -82,13 +82,13 @@ const REMOTE_DOMAIN_ID_LIST_MAX = 16384; const REMOTE_DOMAIN_NAME_LIST_MAX = 16384;
/* Upper limit on cpumap (bytes) passed to virDomainPinVcpu. */ -const REMOTE_CPUMAP_MAX = 256; +const REMOTE_CPUMAP_MAX = 512;
/* Upper limit on number of info fields returned by virDomainGetVcpus. */ -const REMOTE_VCPUINFO_MAX = 2048; +const REMOTE_VCPUINFO_MAX = 4096;
/* Upper limit on cpumaps (bytes) passed to virDomainGetVcpus. */ -const REMOTE_CPUMAPS_MAX = 16384; +const REMOTE_CPUMAPS_MAX = 131072;
/* Upper limit on migrate cookie. */ const REMOTE_MIGRATE_COOKIE_MAX = 16384;
4096 sounds large, but I can't help wondering if we should pre-empt the inevitable and go even bigger. In terms of RPC message size, we can afford to allow 16384 host CPUS and 4096 guest CPUS ?
We can do that. The cpu map for a 16384 host with 4096 guest cpus is 8 MiB large. The RPC message limit is almost 16MiB so we should be fine even with those (now seemingly insane) numbers. I'll send a v2 in a moment.
Daniel
Peter
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Peter Krempa