On Tue, Oct 01, 2013 at 06:57:56PM +0200, Viktor Mihajlovski wrote: > On 10/01/2013 06:19 PM, Daniel P. Berrange wrote: > > > > What were you doing to get a message greater than 256KB ? This > > patch did not attempt to fix all possible combinations. If a > > API call such as virConnectListAllDomains has so much data that > > it requires > 256KB to encode, this fix won't solve that. There > > is nothing we can do for API calls which have a genuine need to > > exceed the old size limit. > > > > I was only addressing the case of virStreamPtr data which was > > mistakenly hardcoded in the server to try sending 16 MB of data > > at once. I switched it to only try to send 256 KB of data per > > stream packet. > > > OK, than it's a misunderstanding from my part (regarding your > intention). The client side error message was the same as in the > "all-at-once" case which would mean that the client somehow > got past receiving the message even then and finally stumbled > trying to decode the message (which is inevitable in such a case). > > Our S390 domains happen to be "oversize" due to the large > number of devices (which is harder to reproduce on a PCI based > system because it runs out of bus addresses too quick). > So dumpxml typically raises the condition. Yep, there's nothing we can do about that scenario with old clients, since the data we're returning is inherantly too big. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list