You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bridge network using VCH in resolv.conf is slow. In particular, this was evident using maridb/mysql with phpmyadmin. phpmyadmin is severely degraded performing operations over the bridge network by hostname.
Environment information
vSphere and vCenter Server version
vCenter 6.5.0.23000
vSphere 6.5.0, 11925212
VIC Appliance version
vic-v1.5.2-7206-92ebfaf5
Configuration
Embedded or external PSC: Embedded
How was the OVA deployed? (Flex client, HTML5 client, ovftool): Flex client
Does the VIC appliance recieve configuration by DHCP? No. VIC is statically assigned
Hostname of vCenter Server: fhp-vcbe.fhpaschen.com
Details
Inside the phpymadmin container using ash, ping by hostname can take as long as 16 seconds to resolve.
Steps to reproduce
Launch a mariadb/mysql container with a "mysql" bridge network docker run -d --name fhp-mysql --network mysql -e MYSQL_ROOT_PASSWORD="password" -e MYSQL_USER="cms" -e MYSQL_PASSWORD="cms" -e MYSQL_DATABASE="xibo" -v mysql-data:/var/lib/mysql/data -p 3306:3306 mariadb
Launch a phpmyadmin container connected to the "mysql" bridge network docker run -d --name fhp-phpmyadmin --network mysql -e PMA_HOST=fhp-mysql -p 8080:80 phpmyadmin/phpmyadmin
Connect to the phpmyadmin web interface and basic operations such as showing existing tables take considerable time to perform.
Running phpmyadmin connected by IP exhibits standard performance docker run -d --name fhp-phpmyadmin --network mysql -e PMA_HOST=172.19.0.2 -p 8080:80 phpmyadmin/phpmyadmin
Troubleshoot by connecting to the phpmyadmin container docker exec -it fhp-phpmyadmin busybox ash
Run "ping fhp-mysql". Can take up to 16 seconds to resolve.
Actual behavior
DNS resolution is extremely slow resulting in poor performance for certain applications which perform many DNS lookups
Expected behavior
Low latency DNS lookups on bridge networks
Support information
Logs
See also
Troubleshooting attempted
Searched GitHub for existing issues. (Mention any similar issues under "See also", above.)
Searched the documentation for relevant troubleshooting guidance.
I have a similar issue. Using the same setup, my containers cannot resolve each others hostnames over the user-defined bridge network; it attempts to resolve the hostnames using the DNS server that was configured during the creation of the VCH. My guess would be that all the containers on the bridge network are attempting to resolve on an external DNS server first, then falling back to the internal DNS.
The behavior that I expect to see is that on the bridge network, the containers do not attempt to use an external DNS server at all. All the DNS resolution should be up to the VCH acting as a forwarder to the configured external DNS servers.
Summary
Bridge network using VCH in resolv.conf is slow. In particular, this was evident using maridb/mysql with phpmyadmin. phpmyadmin is severely degraded performing operations over the bridge network by hostname.
Environment information
vSphere and vCenter Server version
vCenter 6.5.0.23000
vSphere 6.5.0, 11925212
VIC Appliance version
vic-v1.5.2-7206-92ebfaf5
Configuration
Details
Inside the phpymadmin container using ash, ping by hostname can take as long as 16 seconds to resolve.
Steps to reproduce
docker run -d --name fhp-mysql --network mysql -e MYSQL_ROOT_PASSWORD="password" -e MYSQL_USER="cms" -e MYSQL_PASSWORD="cms" -e MYSQL_DATABASE="xibo" -v mysql-data:/var/lib/mysql/data -p 3306:3306 mariadb
docker run -d --name fhp-phpmyadmin --network mysql -e PMA_HOST=fhp-mysql -p 8080:80 phpmyadmin/phpmyadmin
docker run -d --name fhp-phpmyadmin --network mysql -e PMA_HOST=172.19.0.2 -p 8080:80 phpmyadmin/phpmyadmin
docker exec -it fhp-phpmyadmin busybox ash
Actual behavior
DNS resolution is extremely slow resulting in poor performance for certain applications which perform many DNS lookups
Expected behavior
Low latency DNS lookups on bridge networks
Support information
Logs
See also
Troubleshooting attempted
The text was updated successfully, but these errors were encountered: