Configuration of multiple NICs

[WildWon]

Hi there,

When deploying a vm from template currently only one NIC can be configured. Vms with multiple NICs have to be manually reconfigured after deployment.

Terraform Version

Terraform v0.11.10

• provider.vcd (unversioned) built from (git commit 704012e) of the "vmware-takes-ownership" branch

Affected Resource(s)

resource "vcd_vapp_vm"

Terraform Configuration Files

resource "vcd_vapp_vm" "my_vm01" {
	vapp_name = "${var.vappname}"
	name = "${var.vmnamewin}"
	catalog_name = "${var.catalognamewin}"
	template_name = "${var.templatenamewin}"
	memory = 4096
	cpus = 2
	ip = ""
	power_on = false
	network_name = "${var.networkname}"
}

Debug Output

n/a

Panic Output

n/a

Expected Behavior

Being able to either configure all NICs of a template or alternatively add NICs incl. configuration to a vm at deployment.

Actual Behavior

Only one NIC can be configured

Steps to Reproduce

This can be easily reproduced by deploying a new vm to a vCloud instance

Important Factoids

n/a

References

n/a

[lvirbalas]

Thanks @WildWon for this issue!

@vbauzysvmware please have a crack at it. One caveat is that we need to maintain backwards compatibility with existing behaviour.

[dn1s]

I'm working on this feature. Will probably issue a pull request in a couple of days.

[lvirbalas]

@dn1s, that's great. Please take assignment of this task if you can (for some reason GitHub doesn't allow me to select you from the list).

[dn1s]

I have a question about this feature.
Can I deprecate network_name and ip parameter like this: https://www.terraform.io/docs/extend/best-practices/deprecations.html#provider-attribute-removal

In favor of a new parameter networks with a structure like this:

"networks": {
	Type:          schema.TypeList,
	Optional:      true,
	ForceNew:      true,
	ConflictsWith: []string{"ip"},
	Elem: &schema.Resource{
		Schema: map[string]*schema.Schema{
			"orgnetwork": {
				Required: true,
				Type:     schema.TypeString,
			},
			"ip": {
				Computed:         true,
				DiffSuppressFunc: suppressIfIpIsOneOf(),
				Optional:         true,
				Type:             schema.TypeString,
			},
			"ip_address_allocation_mode": {
				Default:      "POOL",
				Optional:     true,
				Type:         schema.TypeString,
				ValidateFunc: checkIpAddressAllocationMode(),
			},
			"is_primary": {
				Type:     schema.TypeBool,
				Default:  false,
				Optional: true,
			},
			"adapter_type": {
				Type:     schema.TypeString,
				ForceNew: true,
				Optional: true,
			},
			"mac": {
				Computed: true,
				Optional: true,
				Type:     schema.TypeString,
			},
		},
	},
},

[dn1s]

I'd be ready to open up a new pr. I have another question though.
When I have a network interface and I want to change the ip_address_allocation_mode afterwards from let's say "POOL" to "DHCP", vmware does not ensure that /etc/sysconfig/network-scripts/ifcfg-eth0 is written properly again. For example it stays like it is. And if I completely remove the file and reboot vm it will create it again only containing "HWADDR" .
So do I have to ensure with the provider this is fixed or should the user fix it?
I probably can fix this in the provider but it would mean to completely remove the nics and attach them again. This might break stuff!
@lvirbalas what's your opinion on this?

[pasikarkkainen]

@dn1s Sounds like the VM needs to do guest customization again (forced re-customization). Normally guest customization is only done on first boot. And that's the component which updates root/admin password, hostname, IP settings, etc.

[dn1s]

@pasikarkkainen After talking a lot about this problem with a college of mine. We came to the conclusion to just force a new vm if network changes since this is out of scope from terraform to handle guestCustomization after initalization. It's probably possible to workaround this problem with providing your own script which is capable of updating network config files in initscript but I would not recommend that.