terraform-provider-vsphere: New 'vapp properties' do not work with Ubuntu 14.04/16.04 OVA

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue trackers reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

terraform-vsphere$ terraform -v
Terraform v0.11.3
+ provider.vsphere v1.3.1

vSphere Provider Version

terraform-vsphere$ terraform providers
.
└── provider.vsphere 1.3.1

Affected Resource(s)

Please list the resources as a list, for example:

  • vsphere_virtual_machine

Terraform Configuration Files

resource "vsphere_virtual_machine" "vm" {
  name             = "terraform-xenial"
  resource_pool_id = "${data.vsphere_resource_pool.pool.id}"
  datastore_id     = "${data.vsphere_datastore.datastore.id}"

  num_cpus = 2
  memory   = 1024
  guest_id = "ubuntu64Guest"

  network_interface {
    network_id = "${data.vsphere_network.network.id}"
  }

  disk {
    name = "terraform-xenial.vmdk"
    size = 40
  }

  vapp {
    properties {
      "password" = "super-secure-password"
      "hostname" = "custom-hostname"
    }
  }

  clone {
    template_uuid = "${data.vsphere_virtual_machine.template.id}"
  }
}

Expected Behavior

VM should have been created, and configured with the provided vApp properties.

Actual Behavior

VM hostname and password are not changed.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply

Important Factoids

Using govc import.ova -options=xenial.json works as expected, where xenial.json looks like:

{
    "DiskProvisioning": "thin",
    "IPAllocationPolicy": "dhcpPolicy",
    "IPProtocol": "IPv4",
    "InjectOvfEnv": false,
    "Name": null,
    "NetworkMapping": [
        {
            "Name": "VM Network",
            "Network": ""
        }
    ],
    "PowerOn": true,
    "PropertyMapping": [
        {
            "Key": "instance-id",
            "Value": "id-ovf"
        },
        {
            "Key": "hostname",
            "Value": "custom-hostname"
        },
        {
            "Key": "seedfrom",
            "Value": ""
        },
        {
            "Key": "public-keys",
            "Value": ""
        },
        {
            "Key": "user-data",
            "Value": ""
        },
        {
            "Key": "password",
            "Value": "super-secure-password"
        }
    ],
    "WaitForIP": false
}

When deploying via vSphere GUI, these options are configurable and work as well.

References

vApp options were added in https://github.com/terraform-providers/terraform-provider-vsphere/pull/303

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 15 (5 by maintainers)

Most upvoted comments

@sdemura I saw! Glad you figured it out and I was suspecting this might be the case.

Sounds like we need to prioritize some of the CDROM update work to ensure that OVF templates with ISO transports work as expected. We have other work that is pending here (#300 and #358), so maybe we can group this all together.

Howdi,

is this fix for this on; https://github.com/terraform-providers/terraform-provider-vsphere/commit/52e17d0197e7eccce39f1dfe2dae139d173e85bb

Looking at that commit it would allow you to specify ClientDevice as CDROm to not force an ISO only mount.

From my testing providing you have a CDROM on the VM which is in ClientDevice mode, then vSphere will pass through the OVF properties in the ISO format in to the running VM, which cloud-init picks up fine.

** Just compiled the provider from master and looks good;

  cdrom {
    client_device = true
  #  datastore_id = "${data.vsphere_datastore.datastore.id}"
  #  path         = ""
  }
	vapp {
    properties {
      "user-data" = "${base64encode("
#cloud-config
yum_repos:
  cx_repo:
   baseurl: \"https://yum-repo01.dev.mycompany.plc/pub/repo\"
   enabled: true
   gpgcheck: false
   name: cx_repo
   sslverify: false
")
	}"
    }
  }

@charandas not that I can speak from 100% experience on the Ubuntu template, but there is a guestinfo transport specifically in cloud-init designed to read user data and other cloud-config keys from guestinfo.ovfEnv which is usually fed in by vApp properties. You can’t edit this key manually - vSphere will overwrite every time you attempt to.

OTOH, if a template does not have a vApp configuration defined, it will fall back to the specific guestinfo keys directly. These can be specified in the advanced configuration of a virtual machine or by using extra_config in the vsphere_virtual_machine resource.

This work was initially contributed here, if I understand correctly.

Of course, cloud-init has been re-implemented a few times by different distros, so these rules may not apply 100%, but I know for sure this works in this fashion on the CoreOS re-implementation.

Hopefully we can work on getting this completely resolved soon the correct way for Ubuntu - delivery via the ISO transport. We are working on a number of updates to CDROM device handling, of which this will be one of them.

Thanks!