On Tue, May 23, 2017 at 10:04:44 +0100, Daniel Berrange wrote: > On Tue, May 23, 2017 at 10:51:47AM +0200, Martin Kletzander wrote: > > On Tue, May 23, 2017 at 09:32:03AM +0100, Daniel P. Berrange wrote: > > > 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. [...] > > Or we can give a hint on what the limit is and let users figure out the > > sensible number. It is not only based on the number of VMs. I believe > > you can hit the limit with one or two VMs if you have lot of devices > > that we report statistics for. Limiting the number of VMs to a > > particular number would not help as much in this case. But we can > > combine both approaches. > > Urgh, that's even worse. Apps can't simply split queries into blocks of > N vms, because any single VM in that list might have huge number of disks. > So to use this at all reliably you have to query the XML config of every > guest to see what devices are present and then split up the queries into > variable number of VMs :-( > > This just adds to my feeling that we should consider this API a failed > experiment Given this metric, any API in libvirt that takes XML is failed in the same sense. You can easily have a VM that exceeds the 4MiB string RPC limit (and 16, or 32) MiB in this sense anyways. Along with metadata, you can reach the limit even easier. A disk information dump returned with this API has slightly above 600 bytes, so let's say 1k, with this metric you can have a VM with 16k disks/nics/whatever, which is reasonable. With the bump to 32MiB, you can obviously have even more. Since this API makes sense (saves time) even if called for a singe VM I don't really think this is a big problem. If you say that the number of VMs you should query is let's say 2 or 4, you can have giant guests. The only non-scalable part is if you have lots of giant guests. You can't really fix that.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
