[qemu][rbd]librbd连接overflow问题

前言： 后端存储使用Ceph卷，在虚拟机中执行mkfs的时候，遇到卡顿。 卡顿位置不确定，有时候是卡在Guest内部执行discard，有时候执行写superblock。 后来发现，是qemu进程的fd超出了限制导致。 分析： 1,discard 主流的存储，尤其是分布式存储，都是支持thin volume，甚至默认都是thin volume的。写时分配可以节省空间，也可以加快volume创建的速度。 排除是否是discard的问题，可以通过libvirt的配置控制开关。 打开discard，<driver discard='unmap'> 关闭discard，<driver discard='ignore'> 实验之后发现，并不是discard导致的。 2,strace 用strace -f -p QEMU-PID的方式来追踪qemu进程的syscall，可以发现，socket失败。 3,limits ls -al /proc/QEMU-PID/fd | wc -l可以确定当前的qemu已经打开的fd数量。 cat /proc/QEMU-PID/limits | grep “Max open files”可以确定当前的qemu最多可以打开的文件的数量，当然，其中也包括TCP连接数量。 发现，确实达到了阈值。 4,netstat netstat -apt | grep QEMU-PID | wc -l 可以发现，一个500G的volume，在Guest里面全盘随机IO之后，大约消耗了接近2K个TCP连接。 那么，就很容易解释为什么qemu的fd爆了。由于qemu的limits是从libvirtd继承过来的，所以，需要修改libvirtd的limits。 5,LimitNOFILE 由于libvirtd是systemd启动的，需要配置systemd的配置。 ibvirt中默认的参数是LimitNOFILE=8192。可以计算出来，可以支持的后端Ceph卷的数量。如果有挂载多个volume的需求，需要扩大这个配置参数。 6,librbd 需要注意的是，尽管因为fd耗尽导致socket失败，但是librbd的api并不会返回error，所以，在qemu的block driver中没有办法处理这个case，也不能report error。 上文修改参数的办法，可以让一个Guest正常工作。但是也有一定的风险。Host上TCP可用的端口共65536个，还有一部分已经reserve起来。 # cat /proc/sys/net/ipv4/ip_local_port_range 确定可用的范围，就可以计算出来一个Host上所有可用的TCP端口数量，进一步计算出来所有可以挂载的Ceph卷的数量。