terraform-provider-vsphere: vApp properties not being set with OVF deployment with provider 1.24.1 and 1.24.2

I’ve recently run into this same issue and have narrowed it down to the resourceVSphereVirtualMachinePostDeployChanges function within the resource_vsphere_virtual_machine code. Here’s the resource i’m trying to create:

resource "vsphere_virtual_machine" "vcsa" {
  name                       = var.vm.name
  resource_pool_id           = data.vsphere_compute_cluster.cluster.resource_pool_id
  host_system_id             = data.vsphere_dynamic.host.id
  datastore_id               = data.vsphere_dynamic.datastore.id
  folder                     = var.vm.folder
  datacenter_id              = data.vsphere_datacenter.dc.id
  ovf_deploy {
    // Url to remote ovf/ova file
    remote_ovf_url = "http://172.16.1.54/software/vmware/vcsa-ova/VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10/VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ovf"
    disk_provisioning = "thin"
    ovf_network_map = {
        "Network 1" = data.vsphere_network.network.id
    }
  }
  vapp {
    properties = {
      # "IpAssignment.IpProtocol"                 = "IPv4"
      # "DeploymentOption"                        = "tiny"
      # "NetworkMapping.Network 1"                = data.vsphere_network.network.name
      "guestinfo.cis.appliance.net.addr.family" = "ipv4" # IP Address Family
      "guestinfo.cis.appliance.net.mode"        = "static" # IP Address Mode
      "guestinfo.cis.appliance.net.addr"        = infoblox_ip_allocation.allocation.ip_addr # IP Address 
      "guestinfo.cis.appliance.net.pnid"        = "${infoblox_ip_allocation.allocation.vm_name}.${infoblox_ip_allocation.allocation.zone}" # IP PNID (same as IP Address if there's no DNS)
      "guestinfo.cis.appliance.net.prefix"      = split("/", data.infoblox_network.nw.cidr)[1] # IP Network Prefix (CIDR notation)
      "guestinfo.cis.appliance.net.gateway"     = data.infoblox_network.nw.gateway # IP Gateway
      "guestinfo.cis.appliance.net.dns.servers" = "172.16.1.98" # Comma separated list of IP addresses of DNS servers.
      "guestinfo.cis.appliance.ntp.servers"     = "172.16.1.90,172.16.1.91" # Comma seperated list of hostnames or IP addresses of NTP Servers
      "guestinfo.cis.appliance.root.passwd"     = var.vm.password # Root Password
      "guestinfo.cis.appliance.ssh.enabled"     = "True" # Enable SSH
      "guestinfo.cis.vmdir.domain-name"         = "auslab.local" # SSO Domain Name
      "guestinfo.cis.vmdir.username"            = "administrator@auslab.local" # SSO Admin Password
      "guestinfo.cis.vmdir.password"            = var.vm.password # SSO Admin Password
      "guestinfo.cis.ceip_enabled"              = "False"
      "guestinfo.cis.deployment.autoconfig"     = "True"
      "domain"                                  = "auslab.cisco.com"
      "searchpath"                              = "auslab.cisco.com"
    }
  }
}

My vapp properties are properly configured initially but then somewhere in this block of code they get erased:

cfgSpec.DeviceChange = virtualdevice.AppendDeviceChangeSpec(cfgSpec.DeviceChange, delta...)
log.Printf("[DEBUG] %s: Final device list: %s", resourceVSphereVirtualMachineIDString(d), virtualdevice.DeviceListString(devices))
log.Printf("[DEBUG] %s: Final device change cfgSpec: %s", resourceVSphereVirtualMachineIDString(d), virtualdevice.DeviceChangeString(cfgSpec.DeviceChange))

// Perform updates
if _, ok := d.GetOk("datastore_cluster_id"); ok {
	err = resourceVSphereVirtualMachineUpdateReconfigureWithSDRS(d, meta, vm, cfgSpec)
} else {
	err = virtualmachine.Reconfigure(vm, cfgSpec)
}
if err != nil {
	return resourceVSphereVirtualMachineRollbackCreate(
		d,
		meta,
		vm,
		fmt.Errorf("error reconfiguring virtual machine: %s", err),
	)
}

vmprops, err := virtualmachine.Properties(vm)
if err != nil {
	return err
}

If i comment out that code and build/use the provider using dev_overrides the vapp properties persist as expected.

Otherwise they are removed and i see a bunch of entries in the logs about vapp properties vanishing.

Confirming, got the same issue. Using 1.24.0 works fine.

@ron4all 100% agree, however, it’s worth mentioning the deployment option capability within this issue as a case for why it doesn’t seem to make sense to call resourceVSphereVirtualMachinePostDeployChanges in its current form at the end of resourceVsphereMachineDeployOvfAndOva since it ultimately wipes the hardware configuration defined within the OVA/OVF along with all of the vApp properties (which is what this issue is referring to).

Thanks!

What I’m still confused about is how I can pass a deployment option value using this provider. This should be a supported feature IMHO.

Thanks!

If passing a “deployment-option” isn’t possible right now, shouldn’t an “enhancement”-request get filed to distinguish it from this topic? //[IMHO - I’m setting up virtual Cisco-Routers and face the same issue not being able to pass the needed “Deployment”-Option (here: Small, Medium, Large or Large + DRAM Upgrade) Blog: OFV-OVA-Properties - when my setup might move to production, I’ll need more horsepower than the (default=)“Small”-Environment.

//just re-read the “issues”-list, there are already 2 threads addressing this: https://github.com/hashicorp/terraform-provider-vsphere/pull/1215 https://github.com/hashicorp/terraform-provider-vsphere/issues/1209

For my opinion i’ll proceed the discussion at 1209

@ron4all I believe this is due to the multiple Reconfigurecalls on the virtual machine. If you skip the resourceVSphereVirtualMachinePostDeployChanges call after the OVA/OVF deploys then the network interfaces will exist along with the hardware outlined by the deployment option (if using). Otherwise that second Reconfigure seems to wipe out all of the hardware config defined in the OVA/OVF.

This is all a guess on my part though so i’ll leave it to the maintainers of the provider to chime in.

Thanks!

@seohs7

I’ve not seen the issue with the URL but this seems to be related to your setup. The URL doesn’t look like it’s pointing to an OVF / OVA file but to a html page but it’s hard to tell just from the URL. However, the issue here seems to be that the VAPP properties are not set. So the deploy part works. I was testing with a local OVA file and saw the same result (VAPP properties empy). I created another issue here https://github.com/pulumi/pulumi-vsphere/issues/144 but the pulumi issue seems to be related to this issue here.

Also while I was researching this issue I saw that vAPP properties will be applies if no config change is performed (e.g. change CPU from what is defined in the OVA & OVF). Once deployed you can change the config and it will work. But it seems like you can’t change the hardware AND set VAPP properties in the first run at once.