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:
terraform apply
Important Factoids
- vSphere 6.5
- Official Ubuntu cloud image: https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64.ova (Note, the Trusty equivalent does not work either)
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)
@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;
@charandas not that I can speak from 100% experience on the Ubuntu template, but there is a
guestinfotransport specifically in cloud-init designed to read user data and other cloud-config keys fromguestinfo.ovfEnvwhich 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
guestinfokeys directly. These can be specified in the advanced configuration of a virtual machine or by usingextra_configin thevsphere_virtual_machineresource.This work was initially contributed here, if I understand correctly.
Of course,
cloud-inithas 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!