ibm-tfproviders/terraform-provider-vsphere

Terraform provider for vsphere

About this repository

This repository created by filtering the subdirectory https://github.com/hashicorp/terraform/tree/master/builtin/providers/vsphere from Git repo https://github.com/hashicorp/terraform

Original README

How to build the teraform provider for vsphere.

1. Export GOPATH and append PATH with $GOPATH/bin
2. Clone or checkout this repository at $GOPATH/src/github.com/IBM-tfproviders
3. cd to $GOPATH/src/github.com/IBM-tfproviders/vmware-vsphere
4. make deps
5. make build

terraform-provider-vsphere's Issues

Datastore/storage cluster names with white spaces is not handled by provider

Issue Description

• Created a terraform vsphere provider pattern to boot a VM by specifying a datastore (having white spaces in the name).

• But terraform apply operation failed while processing the disk path.

• However vsphere client and govc/govmomi successfully boots VM using datastore having white spaces in the name.

Root Cause

• It is an inability of terraform to handle white space in the datastore name
• Terraform is trying to extract the disk path from the vsphere datastore path.
• Syntax of vsphere datastore path: "[DataStore Name] VirtualMachineName/VirtualMachineName.vmdk"
• The above string is being split on " " character to extract the VM disk path.
• Hence the disk path string is splitted wrongly when there is a space in the datastore name.

Open Issue with fix available in the terraform Community:

• The open issue addressing this is: hashicorp/terraform#9174
• The issue has been fixed by applying regex patters to match and extract the substrings.
• Fix is commited but not yet merged with master.

Drawback of regex pattern solution:

• The regular expression again confined to the syntax of vsphere full disk path representation.
• The regex will also fail if there is any change in the syntax of vsphere full disk path representation.

Update/Enhancement added by govmomi to address this Issue:

• The govmomi has provided the fix in the release "govmomi v0.12.1".
• The govmomi has added a helper utility function to parse the datastore path.

Proposed Solution/Fix in Terraform:

• Modify terraform code to use the helper utility function provided by govmomi to parse the datastore path.

Hot changes to VM attributes CPU/Memory not supported

Changes to number of CPUs and memory size always end up rebooting VM even though hot changes are allowed for the target VM.

Storage cluser name is not honoured

When we provide storage cluster name ( instead of data store ) while provisioning a VM, we see an error message from provider stating data store not found.

Similar issue is reported at : hashicorp/terraform#3721

Need support for vDS portgroup resource

A new resource type - portgroup is required in vsphere provider

Add build support

Add Makefile and main entry point for vsphere provider to build "terraform-provider-vsphere" binary

When the VM is powered off, terraform destroy results in a crash

the vm_network_interface.readNetworkData function uses the vm.guest information (namely guest.net and guest.ipstack structures) to determine the list of network interfaces and their associated routing information. When the VM is powered off, the guest.net is unset, resulting in an empty list of network interfaces. guest.ipstack however is set and contains all the routing information, which results in an error condition when we try to update an inexistent deviceID.

Adding a NIC to an existing VM deletes and recreates the VM

Issue:

When a NIC is added to an existing VM, the VM gets deleted and then recreated with the added NIC. If the VM is in use, the contents of the VM are lost as a new VM is created with the added NIC.

The re-provisioning of the VM can be avoided by setting the ForceNew flag to False under the network_interface section. When ForceNew is set to False, terraform calls back the update handler to handle the changes in network_interfaces. Adding a NIC in the update callback encounters a few issues; below are the observations.

Key observations:

1. A NIC addition action from terraform is handled in 2 stages. The first stage where the ethernet device is added and the second stage where the interface is configured with user configuration (if user provides valid input for ipv4_address, ipv4_gateway, etc and doesn't skip customization)

2. The device addition is achieved by invoking ReconfigVM_Task() and the interface configuration is completed by invoking CustomizeVM_Task() vsphere apis.

3. During NIC addition, only the information of device that is to be added should be provided to ReconfigVM_Task() whereas to configure a single interface, configurations of all the interfaces must be provided when making a call to CustomizeVM_Task() as an array.

4. The order of the configurations provided must match with the order of the NICs as seen by vsphere. If there is a mismatch in the order of the configuration, wrong configurations are applied to NICs. Also, if there is a mismatch in the number of configurations provided, an error is thrown.

5. The order of the NICs provided as input in the terraform input file is not guaranteed. When network adapters are added to the VM, the order of the NICs in the VM can be different to the order of addition. This is a known issue. References below:
   hashicorp/terraform#6520
   hashicorp/terraform#7673
   https://communities.vmware.com/thread/484245
   https://communities.vmware.com/thread/443600

6. When adding a NIC and customizing it during update, the order of the network adapters in the terraform input file and the order of NICs in the VM does not match and hence it becomes a challenge to come up with the right order of custom configuration array.

7. Due to this issue, just after a new VM is created (terraform apply), "terraform plan" shows differences although all provisioning is complete and successful.

Suggested Fix:

To overcome this limitation of jumbled network adapters and customizing them as per the user configuration the following approach has been considered.

1. ForceNew flag is set to false. This tells terraform not to delete create the resource (i.e. VM), instead provide a callback to the update handler where the network_interface changes can be handled.

2. When a NIC is added and custom configuration is provided:
   All the network adapters are deleted and re-added to the VM along with the new NIC. By doing so, the order of the adapter addition matches the order of the NIC custom configuration. This guarantees that the configuration is applied to the appropriate network adapters. As it is today, the VM is powered off and powered on to apply the customization. The VM is not deleted and re-created.

3. When a NIC is added but custom configuration is not provided:
   All the network adapters are deleted and re-added to the VM along with the new NIC. This is remain consistent with above flow. The VM is not powered off/on as no customization is done.

4. When a NIC's configuration is changed:
   All the network adapters are deleted and re-added to the VM. Appropriate custom configuration is applied to the adapters. The VM is powered off and powered on to apply the customization.

5. When a NIC is deleted:
   All the network adapters are deleted and the adapters provided/retained in the terraform input file are added to the VM. If custom configuration is provided, the configurations are applied appropriately and the VM is powered off and powered on. This can be enhanced to remove 'deleted NICs' only.

Add support for VApp Resource

This resource can be used to create and delete vApp in vSphere environment.

resource "vsphere_vapp" <"vApp resource name"> {
  name   = <"New vApp name">
  description = <"Description of this new vApp">
  datacenter = <"Datacenter name">
  cluster = <"Cluster name">
  folder = <"Folder name">
  datastore = <"Datastore name">
  resource_pool = <"Resource pool name">
  parent_vapp = <"parent vApp name">

  template_vapp {
      name = <"vApp to be cloned">
      disk_provisioning = <"Disk provisioning format">
      network_mapping {
          source_network_label = <"Source Network label">
          destination_network_label =<"Destination Network label">
      }
  }
}

Creation of vApp happens by cloning an existing vApp only. Update operation is not supported.

Details @ https://github.com/IBM-tfproviders/terraform-provider-vsphere/wiki/Resource-vsphere_vapp

Add support for VM ownership (user permission) change

Terraform should provide support, so that 'Privileged' user can change/assign ownership (i.e. add permission to other user) of virtual machine resource.

A new configuration section, given below, is used to specify the ownership.

permission  {
    role = 'Admin'
    user_name = 'aRegularUser'
}

role -> one of the existing roles pre-created by administrator
user_name -> name of the user going to own this resource

Use cases to be supported by this issue:

• In create VM operation, if 'permission' section is configured, the user will get permission to access the VM resource as per configured role.
• In update VM operation, if 'permission' is configured, user will get permission
• In update VM operation, if 'permission' section is removed, user permission will be revoked
• In update VM operation, if 'permission' section is modified, user permission will be modified accordingly.

Cannot resize the disk - root disk resize fails and other disks gets recreated

The disk resize attempts to recreate the disk with new size - Delete the existing disk and create new disk with new size.

Hence other than root(boot) disk resize, endup loosing data due to disk recreation.
Root disk resize fails due to vpshere API error ( boot disk deletion not allowed on running VM )

Refactoring vDS portgroup resource

Refactoring vDS portgroup code to have following changes:

• Rename NewVdPortgroup function as it parse input ResouceData too.
• Move all 'Schema Validator Function' test logic to a common file, so that other resources can use them if needed.