Re: [RFC][PATCH] Revision for message payload encoding error when adding a large mount of virtio disks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19.04.2012 08:25, Chen Hanxiao wrote:
> From: Chen Hanxiao <chenhanxiao@xxxxxxxxxxxxxx>
> 
> 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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]