[Libvir] Proposed remote protocol (XDR source file qemud/remote_protocol.x)

Daniel P. Berrange berrange at redhat.com
Mon Apr 30 18:00:12 UTC 2007

On Mon, Apr 30, 2007 at 06:42:01PM +0100, Richard W.M. Jones wrote:
> Attached are the args (*_args) and return structures (*_ret) for all the 
> calls covered by the remote protocol, that is to say everything except 
> Save, Restore and CoreDump (see previous email).
> The only problem area are the upper limits imposed on the lengths of 
> various strings and arrays.  The upper limits seem to be required for 
> safely decoding messages from untrusted sources.  Some of them however 
> would impose limits on such things as the number of CPUs supported, and 
> perhaps those limits are too low (or too high)?  I don't really have any 
> experience of the sort of huge machines that people might be running 
> libvirt on.

SGI did a preso at the Xen summit about their 1024 CPU monster ia64
box. So given that such a thing already exists, we need biggger to
account for future developments.

One thing I'm not clear - are these limits actually applied at the
protocol level, or is the protocol completely variable length and
these limits enforced during decoding ?  If the latter, then this
isn't so critical to get perfect, because we can do updates without
breaking back-compat.

> /*----- Data types. -----*/
> /* Maximum total message size (serialised). */
> const REMOTE_MESSAGE_MAX = 262144;
> /* Length of long, but not unbounded, strings.
>  * 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;
> /* A long string, which may NOT be NULL. */
> typedef string remote_nonnull_string<REMOTE_STRING_MAX>;
> /* A long string, which may be NULL. */
> typedef remote_nonnull_string *remote_string;
> /* This just places an upper limit on the length of lists of
>  * domain IDs which may be sent via the protocol.
>  */

On Xen, domain id is a 16 bit quantity. How many concurrent guests should
we account for ? 

> /* Upper limit on lists of domain names. */

However many active guests we support, we need to match that, since
every active guest has a config file somewhere.

> /* Upper limit on cpumap (bytes) passed to virDomainPinVcpu. */
> const REMOTE_CPUMAP_MAX = 256;

Guess this should be 1/8 of  number of CPUs we support. So this gives
us 2048 currently.

> /* Upper limit on number of info fields returned by virDomainGetVcpus. */
> const REMOTE_VCPUINFO_MAX = 2048;

So this is basically the max # of VCPUs we support. 2048 sounds like
way more than enough for virtual CPUs, since one huge machines the
ratio of  phys / virt CPUs is likely to be quite large.

> /* Upper limit on cpumaps (bytes) passed to virDomainGetVcpus. */
> const REMOTE_CPUMAPS_MAX = 16384;

This needs to be based off # phys * # vcpus we support from the earlier
two constants for consistency.

> /* Upper limit on lists of network names. */

Reasonable. I wonder what  max # of bridge devices Linux supports is.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

More information about the libvir-list mailing list