ibm-tfproviders / terraform-provider-vsphere Goto Github PK
View Code? Open in Web Editor NEWLicense: Mozilla Public License 2.0
License: Mozilla Public License 2.0
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
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:
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.
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)
The device addition is achieved by invoking ReconfigVM_Task() and the interface configuration is completed by invoking CustomizeVM_Task() vsphere apis.
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.
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.
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
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.
Due to this issue, just after a new VM is created (terraform apply), "terraform plan" shows differences although all provisioning is complete and successful.
To overcome this limitation of jumbled network adapters and customizing them as per the user configuration the following approach has been considered.
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.
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.
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.
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.
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 Makefile and main entry point for vsphere provider to build "terraform-provider-vsphere" binary
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.
A new resource type - portgroup is required in vsphere provider
Refactoring vDS portgroup code to have following changes:
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.
Changes to number of CPUs and memory size always end up rebooting VM even though hot changes are allowed for the target VM.
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
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 )
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.