VMware Templates Cloned with NIC disconnected

When cloning a packer built (vsphere-iso builder) vmware template, the resulting VM is started with the NIC(s) disconnected. This results in a failure to run cloud-init and the VM being unprovisioned.
Expected outcome:
The VM is cloned with the NIC(s) being in the connected state.
Foreman and Proxy versions:
Foreman version: 1.24.2
Foreman-proxy: 1.24.2
Fog Vsphere: 2.3.1
Fog core: 2.1.0

Distribution and version:
Ubuntu 16.04

After more testing it looks like the bug is in fog-vsphere, I’ll know for sure when I setup a test to use RbVmomi directly.

Hi @brektyme,

thanks for reporting this.
To sum this up: if you clone the template in vsphere it gets cloned with the interfaces conected?
And do you have the interfaces defined on the host that you’re using for the template?

Have you tried different packer machine?
Could you share the packer configuration?

Hi, I’ve done a bit of testing. I tested both Fog and RbVmomi directly the template is cloned with the the interface connected or at least with the start connected attribute being retained. Cloning the template directly results in the same results.

The templates belong to my employer, and I’m not sure they will let me share them. I will say for certain that we’re not doing anything odd with them other than using HCL vs JSON, and using the vsphere-iso builder. The resulting template does have the VM NIC set to start connected.

Is there another modification to the interfaces done by foreman after the clone? I see that in the code it leverages the new_vm method, which adds a new interface to the returned object. That interface though should have the attributes as set in the passed args correct? I tried forcing adding the connectable attribute, with startConnected and connected both true, in the clone_vm method after new_vm returned the VM object, but that didn’t work either.

We’ve also updated our foreman instance toforeman 2.1.2 and ubuntu 18.04.

A good approximation of our templates would be the HCL examples on packer’s github repo. I basically copied those changing just some minor details, and installing cloud-init via the provisioning scripts.

We’re also using vsphere version, with DRS and distributed switches.

Hi I’m still having this issue and have been unable to make any further progress. Is there anything more I can do to troubleshoot this?

Hi, could you try this for me:

  1. Add to “/etc/cloud/cloud.cfg”:
    disable_vmware_customization: true

  2. Add to “/etc/cloud/cloud.cfg”:
    config: disabled

  3. Comment out the 11th line in “/usr/lib/tmpfiles.d/tmp.conf”:
    #D /tmp 1777 root root –

  4. Add to “/lib/systemd/system/vmtoolsd.service” under the [Unit] section:

1 Like

I’ll give this a try today, thanks!

I gave this a try and it didn’t change anything. A couple of notes:

  • We’re using open-vm-tools and not the VMware Tools.
  • I noticed that during the clone, in the web console, the VM Appeared to have been made without a NIC? I didn’t however observe a modification event before the power on so I suspect that this is just how appears since after the clone there was a NIC, but didn’t have start connected enabled.

cloud.log (2.2 KB)

Added current cloud.cfg (had to change extension)

Also we’re building Ubuntu Xenial and Bionic Images not redhat based distros.

Any status on this one? Everything was working fine as far as the NIC coming up enabled and getting an IP assigned when I was using the Kickstart script, except the VM stopped at that point, no registration to Foreman or anything else happening. When I tried using the Cloud-init template, the NIC is disabled and it therefore doesn’t get an IP address from cloud-init.

Deploying a CentOS 7 VM on vSphere 6.7.

Answering my own question on this one:

RTFM :slight_smile:

Configure cloud-init to Skip Networking

Drop in a configuration stub to instruct cloud-init to skip network configuration:

[root@localhost ~]# cat << EOF > /etc/cloud/cloud.cfg.d/01_network.cfg
  config: disabled

Note: Satellite will do this via the Vmware customisation specification).

I did this, deployed a new VM, and it worked perfectly. NIC enabled, IP and hostname assigned.

Although I’m getting a different cloud-init error now:
DataSourceNoCloud.py[DEBUG]: Seed from http://foreman/userdata/ not supported by DataSourceNoCloud [seed=none][dsmode=net]

And Foreman just sits there with Build: Pending Installation indefinitely.

1 Like