Created attachment 298201 [details] kernel 2.6.39 config I have use next packages: app-emulation/qemu-kvm-0.15.1-r1 and app-emulation/libvirt-0.9.8 On kernel 2.6.39-gentoo-r3 virsh starts virtual machine (V) with command: qemu-system-x86_64 --enable-kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name test -uuid aafcf309-9b2f-021f-1335-7d3ee695120e -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/dev/vg/sys-gentoo-amd64-syslog,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=16,id=hostnet0,vhost=on,vhostfd=17 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fc:6b:35,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 and all works fine: from host with virtual machine (A) and external host (B) takes TCP/UDP/ICMP connections. After upgrade kernel to 3.0 and 3.1 TCP connections with V not establish. There is on A: # brctl show br3 bridge name bridge id STP enabled interfaces br3 8000.00259005540c yes bond1.3 vnet0 There is on V: # netstat -lnap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 3697/slapd tcp 0 0 0.0.0.0:56575 0.0.0.0:* LISTEN 3639/rpc.mountd … Test TCP connection to V with command: telnet 192.168.1.122 636 There is tcpdump output on destination V: # tcpdump -i eth0 -n 'host 192.168.1.210' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 04:04:01.980335 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 64614 0,nop,wscale 8> 04:04:04.990534 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 64915 0,nop,wscale 8> 04:04:11.000494 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 65516 0,nop,wscale 8> There is tcpdump output on source B: # tcpdump -i br3 -n 'host 192.168.1.122 ' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br3, link-type EN10MB (Ethernet), capture size 96 bytes 04:04:03.852997 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 64614 0,nop,wscale 8> 04:04:06.862985 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 64915 0,nop,wscale 8> 04:04:12.872983 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 65516 0,nop,wscale 8> but when source of TCP is A, then all works fine: tcpdump -i br3 -n 'host 192.168.1.122 and tcp port 636' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br3, link-type EN10MB (Ethernet), capture size 96 bytes 04:07:42.502219 IP 192.168.1.209.60449 > 192.168.1.122.636: S 3713155501:3713155501(0) win 18236 <mss 9118,sackOK,timestamp 122580 0,nop,wscale 8> 04:07:42.502454 IP 192.168.1.122.636 > 192.168.1.209.60449: S 3882010051:3882010051(0) ack 3713155502 win 14480 <mss 1460,sackOK,timestamp 1089495 122580,nop,wscale 4> 04:07:42.502500 IP 192.168.1.209.60449 > 192.168.1.122.636: . ack 1 win 72 <nop,nop,timestamp 122580 1089495> 04:07:44.911105 IP 192.168.1.209.60449 > 192.168.1.122.636: F 1:1(0) ack 1 win 72 <nop,nop,timestamp 122821 1089495> 04:07:44.911807 IP 192.168.1.122.636 > 192.168.1.209.60449: F 1:1(0) ack 2 win 905 <nop,nop,timestamp 1091904 122821> 04:07:44.911841 IP 192.168.1.209.60449 > 192.168.1.122.636: . ack 2 win 72 <nop,nop,timestamp 122821 1091904> In some time V cannot connect to B, but connect to A. Any other protocols (ICMP/UDP) works on A,B to/from V. iptables on A: iptables -L -nv Chain INPUT (policy ACCEPT 54417 packets, 87M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 10654 packets, 798K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 42428 packets, 10M bytes) pkts bytes target prot opt in out source destination ebtables on A: ebtables -L Bridge table: filter Bridge chain: INPUT, entries: 0, policy: ACCEPT Bridge chain: FORWARD, entries: 0, policy: ACCEPT Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Kernel configs 2.6.39 and 3.x has minimal differences. Any other parts of systems are equal. Problems with TCP are depends on kernel version.
Created attachment 298203 [details] kernel 3.0.6 config
Created attachment 298205 [details] kernel 3.1.6 config
Hi Evgeny, sorry to tell you this, but it works fine for me with: Kernel 3.0.4-gentoo libvirt-0.9.8 qemu-kvm-0.15.1-r1 Be careful when live-migrating VMs from an older libvirt version to a newer one - my VMs got stuck then and hung.
I'm testing with kernel 3.2 and got some problem.
> Hi Evgeny, Hello. > sorry to tell you this, but it works fine for me with: > Kernel 3.0.4-gentoo Can you post your kernel configuration file?
Created attachment 303765 [details] linux-3.2.6 Kernel config
I have lots of different configs running with 3.x, e.g.: sys-kernel/gentoo-sources-3.2.6 app-emulation/qemu-kvm-1.0-r3 app-emulation/libvirt-0.9.10-r3 qemu-system-x86_64 -boot d -cdrom ipxe.iso -m 256 -net nic,macaddr=00:11:22:33:44:55,model=virtio -net tap,script=/etc/qemu-ifup -enable-kvm -monitor unix:/tmp/gpxe,server,nowait -balloon virtio There is no issue at all for me.
I'm curious if this issue is solved for you in kernel 3.3_rc5. Can you test with that and confirm?
Well, let us know if this is solved by a newer kernel. I can't duplicate this issue.
