[libvirt] error: server response too large

[Daniel P. Berrange]

On Tue, Oct 01, 2013 at 06:13:10PM +0200, Viktor Mihajlovski wrote:
> On 10/01/2013 03:02 PM, Daniel P. Berrange wrote:
> >On Mon, Sep 30, 2013 at 04:24:49PM +0100, Daniel P. Berrange wrote:
> >>On Mon, Sep 30, 2013 at 05:23:33PM +0200, Michal Privoznik wrote:
> >>>On 30.09.2013 17:02, Claudio Bley wrote:
> >>>>Hi.
> >>>>
> >>>>When trying to do a screenshot of a remote domain connected via
> >>>>qemu+tcp (for testing purposes only), I receive this error:
> >>>>
> >>>>----------------------------------------------------------------------
> >>>>virsh -c qemu+tcp://dev/system
> >>>>Welcome to virsh, the virtualization interactive terminal.
> >>>>
> >>>>Type:  'help' for help with commands
> >>>>        'quit' to quit
> >>>>
> >>>>virsh # version
> >>>>Compiled against library: libvir 0.9.8
> >>>>Using library: libvir 0.9.8
> >>>>Using API: QEMU 0.9.8
> >>>>Running hypervisor: QEMU 1.5.1
> >>>>
> >>>>virsh # screenshot 2 /tmp/screendump
> >>>>error: could not receive data from domain 2
> >>>>error: packet 1048600 bytes received from server too large, want 262144
> >>>>
> >>>>virsh # 2013-09-30 14:47:05.158+0000: 21646: info : libvirt version: 0.9.8
> >>>>2013-09-30 14:47:05.158+0000: 21646: warning : virNetClientIncomingEvent:1660 : Something went wrong during async message processing
> >>>>----------------------------------------------------------------------
> >>>>
> >>>>I'm using Ubuntu LTS 12.04.3, latest version in the repo which is
> >>>>0.9.8-2ubuntu17.13.
> >>>
> >>>This works as expected. 0.9.8 still had a small buffer for RPC messages.
> >>>It's since 0.9.13 release that we've switched to dynamically allocated
> >>>buffer and hence could size up the limit for incoming data. Update the
> >>>client and problem will just go away.
> >>
> >>Actually that is not working as expected. The old client should *always*
> >>be able to talk to a new server. If the new server is unconditionally
> >>sending back data that is too large for the client, this is a bug.
> >
> >This problem was fixed in
> >
> >commit 27e81517a876dcb738dd8a9bb2e0e68d71c3b7e3
> >Author: Daniel P. Berrange <berrange at redhat.com>
> >Date:   Mon Sep 30 17:27:51 2013 +0100
> >
> >     Fix max stream packet size for old clients
> >
> >     The libvirtd server pushes data out to clients. It does not
> >     know what protocol version the client might have, so must be
> >     conservative and use the old payload limits. ie send no more
> >     than 256kb of data per packet.
> >
> >
> >And backported to stable branches.
> >
> >Daniel
> >
> I tried libvirt 1.1.3 containing the commit on the server and
> Ubuntu libvirt 0.9.8 as the client and still have the issue
> if the message is greater than 256KB. The problem is that
> the old client checks the message size during decode (which is
> greater than the client's max message size).
> 
> Not sure how to get out of this ...

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.

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