[libvirt] [RFC PATCH 2/2] lib: Add note that bulk stats API queries may overrun RPC buffers

[Martin Kletzander]

On Mon, May 22, 2017 at 06:00:13PM +0200, Peter Krempa wrote:
>Hint that the users should limit the number of VMs queried in the bulk
>stats API.
>---
> src/libvirt-domain.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
>index 310b91b37..b01f2705c 100644
>--- a/src/libvirt-domain.c
>+++ b/src/libvirt-domain.c
>@@ -11315,6 +11315,10 @@ virConnectGetDomainCapabilities(virConnectPtr conn,
>  * VIR_CONNECT_GET_ALL_DOMAINS_STATS_SHUTOFF and/or
>  * VIR_CONNECT_GET_ALL_DOMAINS_STATS_OTHER for all other states.
>  *
>+ * Note that this API is prone to exceeding maximum RPC message size on hosts
>+ * with lots of VMs so it's suggested to use virDomainListGetStats with a
>+ * reasonable list of VMs as the argument.
>+ *
>  * Returns the count of returned statistics structures on success, -1 on error.
>  * The requested data are returned in the @retStats parameter. The returned
>  * array should be freed by the caller. See virDomainStatsRecordListFree.
>@@ -11386,6 +11390,9 @@ virConnectGetAllDomainStats(virConnectPtr conn,
>  * Note that any of the domain list filtering flags in @flags may be rejected
>  * by this function.
>  *
>+ * Note that this API is prone to exceeding maximum RPC message size on hosts
>+ * with lots of VMs so it's suggested to limit the number of VMs queried.
>+ *

Makes sense to me, now we can at least point people somewhere when this
happens again.  ACK from me, but feel free to wait if you want to really
make this an RFC and you want more opinions.

Is there a discussion about how to continue for the future?  I remember
Michal starting some discussion, but I'm not sure whether that was about
the same thing.  Anyway, that's just a rhetorical question so that I can
say the two ideas I have:

 1) Just increase the limit over time.  Computers and networks are
    getting faster, there's more storage space and memory, and so on.
    It only makes sense to do scale other things respectively.

 2) Have a new API that streams the data back over virStream.  We can
    then do it continuously (like every X seconds), that might help
    management apps as well because I suspect that's how they use this
    API anyway.

Thanks for listening ;)

>  * Returns the count of returned statistics structures on success, -1 on error.
>  * The requested data are returned in the @retStats parameter. The returned
>  * array should be freed by the caller. See virDomainStatsRecordListFree.
>--
>2.12.2
>
>--
>libvir-list mailing list
>libvir-list at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170523/ebe09ec3/attachment-0001.sig>