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