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 :|