On 19.04.2012 08:25, Chen Hanxiao wrote:
From: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
When adding a large number of virtio storage devices to virtual machine by using 'virsh edit' command, there is a problem: When we added more than 190 virtio disks by 'virsh edit' command, we got a feedback as 'error: Unable to encode message payload'. In virt-mananger, the same defect occurs with about 180 virtio disks added.
PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest, 4 are not removable. This means there are up to 28 free PCI slots available for additional devices per guest. Each PCI device in a guest can have up to 8 functions. One slot kept for network interface, we could add at most 216 (27*8) virtio disks. The length of xml description with multifuction for one virtio disk is about 290 characters; In virt-manger, an extra tag 'alias name' will come to the xml description, which would add about 40 more characters. So for one xml description, 330 characters would be enough. A brand new virtual machine with one IDE bus disk needs about 1900 characters for xml description.
In src/remote/remote_protocol.x, there is a limitation for XDR enoding length as REMOTE_STRING_MAX. According to the analysis above, at least 73180(1900+216*330) characters are needed for 216 virtio disks. In the view of variable length in tag 'source file', so I think it would be better to extend this limitation from 65536 to 80000. --- src/remote/remote_protocol.x | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x index 2d57247..2c8dcbb 100644 --- a/src/remote/remote_protocol.x +++ b/src/remote/remote_protocol.x @@ -65,7 +65,7 @@ * This is an arbitrary limit designed to stop the decoder from trying * to allocate unbounded amounts of memory when fed with a bad message. */ -const REMOTE_STRING_MAX = 65536; +const REMOTE_STRING_MAX = 80000;
/* A long string, which may NOT be NULL. */ typedef string remote_nonnull_string<REMOTE_STRING_MAX>;
While this limit is pretty harmless, the much bigger issue is - a per message buffer of VIR_NET_MESSAGE_MAX bytes which is hold during whole API. I am writing a code to allocate this buffer dynamically based on message length. btw: don't you want size up VIR_NET_MESSAGE_STRING_MAX in virnetprotocol.x as well? Michal