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.
With SCSI it's easier to create large guests, so a script like
the one below can help to reproduce...
#!/bin/bash
cat > scsidom <<EOF
<domain type='kvm'>
<name>manydevs</name>
<memory>1048576</memory>
<os>
<type>hvm</type>
</os>
<devices>
<controller type='scsi' model='virtio-scsi'/>
EOF
for i in {1..1000}
do
cat >> scsidom <<EOF
<disk type='file' device='disk'>
<source file='/var/lib/libvirt/images/vol$i'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0'
target='0' unit='$i'/>
</disk>
EOF
done
cat >> scsidom <<EOF
</devices>
</domain>
EOF
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294