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.