Can you share vdsm.log of the VM statup (since VM.create to Up state)?

Can you share your `brctl show` as well as your bridge's connectivity to the outside world?

Can you try installing vdsm-hook-macspoof.rpm and configuring it on you VM interface? (Cf. http://www.ovirt.org/Vdsm_Hooks to learn how) Just to rule out a set of other issues.

Created attachment 1103484 [details]
bridge details

Created attachment 1103485 [details]
Network overview

Created attachment 1103487 [details]
vdsm log

I installed vdsm-hook-macspoof at the host and did the config change in the engine, also created the macspoof key at the VM.

There is no change in the behaviour, still packets lost.

thanks, Thomas. Can you provide more information about your guest OS and applications (versions, which containers)?

Federico, have you noticed anything like this during your integration work http://www.ovirt.org/images/d/dd/2014-ovirt-docker-integration.pdf ?

We are running CentOS 7.1 x86_64 with the latest updates on all components:

- Host
- VM
- Docker container

The CentOS 7.1 of the VM and the container are minimal installations.

The docker RPMs in the VM are out of the CentOS-7.1-Extras repository.


We start the container via the command line

    docker run -it centos /bin/bash


When we start the container with the network mode bridging (IP address of the VM is used) instead of nat, we do not face the network problem:

    docker run -it --net=host centos71 /bin/bash

But based on our application we need to run multiple containers within a VM which must be accessible from outside and therefore the bridging option is not an option for us.



I tried a different way of installation at one host:

- Install the CentOS 7.1 via PXE
- Install KVM (qemu-kvm, libvirt & virt-manager RPMs)
- Attach the host into an oVirt cluster
- Migrate an existing VM with a running container to this newly installed host

There the container was able to access the internet.
But after a reboot of this host the problem was present again.
 
So some part of the KVM installation seemed to do some changes which were reverted after teh reboot.

In the VM we are running docker 1.8.2:

[root@dc2-ovm1 /]# docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Package Version: docker-1.8.2-7.el7.centos.x86_64
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Package Version:
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:
 OS/Arch:      linux/amd64

Hello, I tried to reproduce your problem, but with no success.

I started CentOS docker container with mapped ports 8000:8000 on CentOS VM and then tried to ping VM:8000 via https://code.google.com/archive/p/paping/, but no packets were lost. When I tried to ping outside network from container itself via ICMP ping it was OK as well.

Could you please check if my steps were wrong or the bug is not there anymore?

Have you used some special iptables rules other than Docker port mapping?

Thanks,
Petr

Hi,

we have not used any port mapping for the Docker container.

In the container we used curl for testing a HTTP access to a server.

E.g. in the container just run 

    curl http://www.google.com

or any other web site.

I use to run tcpdump in parallel at the docker bridge in the VM and at the outgoing interface of the VM.
There I spotted that acknowledgement packets from the HTTP access are arriving at the VM interface but not forwarded to the docker bridge, so never reaching the Docker container.

For the Docker container, we haven't modified any iptables rules.
Only what was configured by Docker itself.

We still find it hard to reproduce your condition.

Do you still see it? Have you tried newer versions of docker or ovirt since?

Can you share a sanitized tcpdump, so we could attempt to understand which packets are lost, and when?

Hello again,

I ran `curl www.google.com` 1000 times (poor Google) while `tcpdump -i eth0 -s 65535 -w eth0_1000.pcap` and `tcpdump -i docker0 -s 65535 -w docker0_1000.pcap` were running. I checked captured traffic (docker0_1000.pcap and eth0_1000.pcap) via Wireshark, some requests myself, the rest via tcp.analysis.lost_segment filter and I was not able to find any lost segments/dropped packets there.

Could you please try the same yourself to see if my test was invalid of if it is just working in my environment?

Thank you very much.

I just retested with CentOS 7.3 as the OS in the VM (with latest updates).

For docker I installed docker-engine-1.13.1.

Here I can run a wget inside the docker container and pull an ISO image without any packet loss.

Thanks for the response, closing as NOTABUG, please reopen if it appears again.