SlowTimer issue using Composer under vagrant-parallels

[jdhiro]

This isn't a new issue, but it wasn't fixed with Parallels 10 so I'm opening the issue now. Related issues:

97

https://github.com/mitchellh/vagrant/issues/1172

My configuration: MacBook Pro Retina Parallels 10 + vagrant-parallels Vagrant 1.6.5

Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.provision "shell", path: "Vagrant/bootstrap.sh"  
  config.vm.hostname = 'devbox'

  config.vm.define "local", primary: true do |local|
    config.vm.box = "ubuntu/trusty64"
    local.vm.provider :virtualbox do |vb|
      vb.memory = 2048
      vb.cpus = 1
      vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
    end
    local.vm.provider :parallels do |p, override|
      override.vm.box = "parallels/ubuntu-14.04"
      p.update_guest_tools = true
      p.memory = 2048
      p.cpus = 1
    end
  end
end

My stack: Ubuntu 14.04 HHVM Nginx Laravel

Repro steps:

1. Create the new Vagrant machine
2. Install HHVM and Laravel
3. Install Composer
4. In the Laravel directory, run ./composer update

Laravel depends upon Composer for package management. The problem is that composer install constantly hits SlowTimer errors in a default environment. Upon further investigation, this seems to be related to IPv6 DNS lookups, which always timeout after 5 seconds. This exceeds the default 5 second timeout of HHVM (which can be awkwardly increased, but I think the root of the problem needs to be addressed).

With a VirtualBox provider, this issue can be resolved via:

    local.vm.provider :virtualbox do |vb|
      vb.memory = 2048
      vb.cpus = 1
      vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
    end

However, vagrant-parallels has no similar configuration. I have also discovered that I can work around this issue by adding the following into my servers configuration script:

echo options single-request-reopen >> /etc/resolvconf/resolv.conf.d/head
resolvconf -u

Frankly, I don't understand what this really does. Something about opening IPv6 requests on another socket... not sure. It seems like a workaround for bad behavior.

I've tried using default shared networking, private networking, and public networking. All of them have the same issue.

[legal90]

@jdhiro, Thank you for a detailed information. I've followed by your instruction and this issue is really reproducing sometimes (not constantly, but it doesn't matter).

As we see, this issue is related to Linux distributions themselves, but not to specific virtualization tool. Roots are in the glibc library: https://bugzilla.redhat.com/show_bug.cgi?id=459756 https://bugzilla.redhat.com/show_bug.cgi?id=505105 (Seems like it is common with Ubuntu distributions)

Unfortunately, Parallels Desktop doesn't have such options like as natdnshostresolver and natdnsproxy in VirtualBox. So that we can not do anything with this in our provider for Vagrant.

I suggest that the most correct decision here is using single-request-reopen option in the resolver conviguration. What it really does is described here:

Implement second fallback mode for optimized DNS lookup for even more broken environments. If two requests from the same port are not handled correctly close the socket and open a new one before sending the second request. The 'single-request-reopen' option in /etc/resolv.conf can be used to select this mode right away, instead of rediscovering the necessity is every process again.

This behaviour is used by default in baseboxes from Bento (the popular box collection maintained by Chef) Read this: https://github.com/mitchellh/vagrant/issues/1172#issuecomment-42263664

P.s. Since there is nothing to do in provider, this issue should be closed. Sorry about that :-(

[legal90]

Perhaps, we should to rebuild our boxes with single-request-reopen enabled (like it is done in Bento's boxes).

[jdhiro]

@legal90 thank you for the quick response. Honestly, I like that the parallels box is more or less a stock configuration. I can deal with the workaround, and hopefully this issue will help others who run into it. I wouldn't want to cause a problem for another person/tool who was expecting the out-of-box configuration.

[legal90]

hopefully this issue will help others who run into it.

Yes, sure! This thread is useful for everybody who are faced with this issue. Thank you for filing it.

[bassam]

On some boxes where /etc/resolv.conf is managed by systemd (like CoreOS) its non trivial to add the option to resolv.conf. I really wish parallels desktop had support for natdnshostresolver1 to workaround this.

[legal90]

Reopened due to the report from @bassamtabbara in https://github.com/Parallels/vagrant-parallels/issues/97#issuecomment-173808484:

---

I've narrowed the issue a little more.

I have the following setup. My host machine OSX El Capitan as the following in its /etc/resolv.conf:

nameserver 192.168.0.1
nameserver 2001:558:feed::1
nameserver 2001:558:feed::2

When I boot a modern Linux guest machine (such as CoreOS) and use Shared Networking with default settings in Parallels (DHCP v4 and v6 enabled), DNS resolution fails on the guest. For example:

core@coreos01 ~ $ curl http://www.parallels.com 
curl: (6) Couldn't resolve host 'www.parallels.com'

I can workaround this in two ways: 1) turn off IPv6 on the host 2) add the following to /etc/resolv.conf on the guest "option single-request-reopen"

Both of these are workaround and the real problem seems to be in the DNS implementation inside Parallels Desktop. This problem does not happen on VMWare Fusion, nor Virtualbox.

[legal90]

@bassamtabbara I've tried to reproduce it from the scratch with box AntonioMeireles/coreos-alpha v899.1.0, but everything works fine for me. If the issue appears constantly in your case, could you please provide a reproduction scenario? It would be good to know the name and version of Vagrant box and version of Parallels Desktop you are using.

P.s. @dskr99, could you please also assist here?

[bassam]

I have a reliable repro. I'm on OSX 10.11.3 and PD Business 11.1.2 (32408). The issue seems to occur when the host has an IPv6 address and corresponding DNS entries. Here are the step to reproduce:

Ensure IPv6 is enabled on the host (for your default adapter):

networksetup -setv6automatic Wi-Fi

Make sure you have a IPv6 address assigned:

ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 80:e6:50:1b:81:c0 
    inet 192.168.0.13 netmask 0xffffff00 broadcast 192.168.0.255
    inet6 fe80::82e6:50ff:fe1b:81c0%en0 prefixlen 64 scopeid 0x4 
    inet6 2601:602:8000:a000:82e6:50ff:fe1b:81c0 prefixlen 64 autoconf 
    inet6 2601:602:8000:a000:fd25:6d9b:783f:45d7 prefixlen 64 autoconf temporary 
    nd6 options=1<PERFORMNUD>
    media: autoselect
    status: active

and IPv6 DNS servers:

cat /etc/resolv.conf 
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 192.168.0.1
nameserver 2001:558:feed::1
nameserver 2001:558:feed::2

Now run the following:

vagrant init AntonioMeireles/coreos-alpha
vagrant up
vagrant ssh
curl http://www.parallels.com
curl: (6) Couldn't resolve host 'www.parallels.com'

If you disable IPv6 on the host:

networksetup -setv6off Wi-Fi

and repeat the curl operation succeeds.

[dskr99]

@bassamtabbara Could you please collect the tcpdump inside guest and a bit of more information? The steps are

1) Turn on detailed logging in Parallels (Parallels Desktop -> Preferences -> Advanced -> select "Use detailed log messages" 2) in guest start the command "sudo tcpdump -i eth0 -s 65535 -w dump.pcap" 3) reproduce the problem and stop the tcpdump 4) send a problem report (Parallels Desktop -> Help -> Send technical data) and the turn off detailed logging

Then send me the file dump.pcap and problem report number to sdmitry_at_parallels.com

[bassam]

@dskr99 done. let me know if you need anything else.

[dskr99]

It is a strange issue happens: I see that Parallels doesn't receive any DNS-reply when IPv6 is enabled on host. Could we organize a remote WebEx-like session to investigate the problem? I expect that it will take about 40 minutes.

PS: I'll duplicate this message via email

[legal90]

@dskr99 @bassamtabbara Do you have any updates on this? Is the issue still actual?

[bassam]

Yes. Its an issue with parallels DNS resolution. If there is a slow DNS server, it seems that parallels will wait for a long timeout period. @dskr99 said he has some ideas for fixing it -- and that would require a fix in parallels desktop itself. A workaround is to disable IPv6 networking. @dskr99 might want to add the workaround steps here.

[ianregister]

Hey people. I spent an age working out this issue for my particular Vagrant set up. It worked for VirtualBox and Fusion, so might also for you Parallel folks. See here:

https://github.com/mitchellh/vagrant/issues/1807#issuecomment-254383077

[legal90]

I'm closing this issue due to the long period of inactivity. If it is still actual - feel free to create a new one.