I am unable to test or maintain issues specific to the VMWare Fusion provider.

@posita was the original author in this space and may be able to assist getting issues specific to that provider up to speed with latest project changes.

I suspect the issue is rooted in not moving up to Fedora 21. Not moving to Fedora 21 will result in running with older versions of Docker since Fedora 20 is no longer packaging Docker updates, so if you want to debug this further, I would move up to a Fedora 21 box similar to what was done for the Virtual Box provider here:

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/Vagrantfile#L66

If @posita is unable to assist, and you are not able to contribute a satisfactory fix, I am inclined to remove support for VMWare Fusion as part of Kubernetes 1.0 release.

If @posita is unable to assist, and you are not able to contribute a satisfactory fix, I am inclined to remove support for VMWare Fusion as part of Kubernetes 1.0 release.

To be clear, I basically guessed at many VMWare implementation details when I hijacked #2741 from @jameskyle.¹ @jameskyle, I'm willing to assist with a fix for this, but I would need your guidance. Do you have any idea as to the cause?

¹ This was because I don't have licenses for either Fusion or Workstation (see this and this).

I have a license for Fusion and the associated Vagrant plugin. I was able to reproduce the original issue. Upgrading the box to Fedora 21 lead to a different error when provisioning the master:

ARPCHECK=no /sbin/ifup eth1 2> /dev/null

Stdout from the command:

ERROR    : [/etc/sysconfig/network-scripts/ifup-eth] Device eth1 does not seem to be present, delaying initialization.

I'm willing to help troubleshoot and put together a PR to address.

Further investigation shows that the error I'm getting is a vagrant issue, not a kubernetes issue. I'll see if I can find a solution.

I am making progress in getting this running. The master and node(s) are now getting to the provisioning step.

I had to upgrade Vagrant to 1.7.3 to get over networking related issue.

This is a known issue [1] with vmware images that can be fixed by ensuring that HWADDR entries in ifcfg-* are deleted on cleanup during image build [2]. Ideally the default vmware image should be fixed, but if that's not possible, the provision scripts could conditionally update the network device script with the device's actual mac:

ifname=eth0
mac_address=$(ip addr show dev ${ifname} | grep ether | awk '{print $2}')
sudo sed -i -e "s+^\(HWADDR=\).*+\1${mac_address}+" /etc/sysconfig/network-scripts/ifcfg-${ifname}
sudo systemctl restart network.service

1: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2002767
2: https://groups.google.com/forum/#!topic/packer-tool/UZ7rSpKKgyo

Scratch that, removing the HWADDR entry did not work. Removing the interface scripts entirely at the end of image construction did resolve the issue:

rm /etc/sysconfig/network-scripts/ifcfg-[ep]*

@marun Hm, removing the HWADDR is one of a few post flight cleanup tasks for vagrant boxes.

For a complete overview of cleanup tasks for networking, my packer build scripts are fairly tested:

https://github.com/jameskyle/packer-vagrant/blob/master/scripts/network.sh

function configs() {
    rm -f /etc/udev/rules.d/70-persistent-net.rules
    rm -f /etc/sysconfig/network-scripts/ifcfg-eno*
    ln -sf /dev/null /etc/udev/rules.d/80-net-name-slot.rules
    sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-*
    sed -i "/^UUID/d" /etc/sysconfig/network-scripts/ifcfg-*
    cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-eth0
# Generated by packer image builder
DEVICE="eth0"
ONBOOT=yes
NETBOOT=yes
IPV6INIT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
NAME="eth0"
EOF
}

@marun, @jameskyle

The box that we are currently using were built through Bento. They do not appear to have the same clean up strategy and are leaving behind a /etc/sysconfig/netowrk-scripts/ifcfg-en33 file and associated interface.

I'm open to work on a custom Fedora box that will incorporate the appropriate clean up steps and posting it somewhere where it is going to be available.

Same problem with Parallels.
Quick workaround (waiting for a fix on the upstream box):

mkdir kubertemp
cd kubertemp/
vagrant init kube-fedora20
vagrant up
vagrant ssh -- sudo rm -f /etc/udev/rules.d/70-persistent-net.rules /etc/sysconfig/network-scripts/ifcfg-eth*
vagrant ssh -- sudo poweroff
vagrant package 
vagrant destroy -f
vagrant box remove kube-fedora20
vagrant box add --name kube-fedora20 package.box

Hmm, the last work around doesn't work for vmware_fusion and vagrant. "vagrant package" is not supported.

I resolved the issue under vmware_fusion by leaving the default SSH insecure vagrant keys in place while building the middle box solution that @dguerri suggested.

mkdir kubertemp && cd kubertemp
vagrant init kube-fedora20

# add config.ssh.insert_key = false into Vagrantfile

vagrant up

vagrant ssh -- sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
vagrant ssh -- sudo rm -f /etc/sysconfig/network-scripts/ifcfg-eno*
vagrant ssh -- sudo ln -sf /dev/null /etc/udev/rules.d/80-net-name-slot.rules
vagrant ssh -- sudo sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-*
vagrant ssh -- sudo sed -i "/^UUID/d" /etc/sysconfig/network-scripts/ifcfg-*
vagrant ssh -- sudo cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-eth0

vagrant ssh -- sudo poweroff

# package it
export BOX_KTEMP=`pwd`
cd .vagrant/machines/default/vmware_fusion/<machine__uuid>
tar cvzf package.box ./* && mv package.box $BOX_KTEMP && cd $BOX_KTEMP

vagrant destroy -f
vagrant box remove kube-fedora20
vagrant box add --name kube-fedora20 package.box

Just to help a bit, I am on ubuntu 14.04 with workstation 10.0.6 and vagrant 1.7.4. I had the same MAC address issue. I tried upgrading to the fedora21 box and got past the network adapter configuration but ran into another error

==> master: Configuring network adapters within the VM...
==> master: Waiting for HGFS kernel module to load...
==> master: Enabling and configuring shared folders...
    master: -- /home/mpollack/software/kubernetes: /vagrant
==> master: Running provisioner: shell...
    master: Running: /tmp/vagrant-shell20151110-7889-196ijzy.sh
==> master: grep: 
==> master: /etc/sysconfig/network-scripts/ifcfg-eth1
==> master: : No such file or directory
==> master: Job for network.service failed. See "systemctl status network.service" and "journalctl -xe" for details.

I'll try @tom-haines suggestion another time....

Looks like creating a vmware provider package is rather complicated.... so guess I'll have to try another way to run k8s. Hope this gets sorted out soon.

@kubernetes/sig-testing-misc @kubernetes/sig-cluster-lifecycle-misc

Closing as obsolete, please reopen if this is still an issue.