-
Notifications
You must be signed in to change notification settings - Fork 9.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
azurerm - error when trying to create a VM with multiple NICs - Network interface must have Primary property set #6514
Comments
Hi @dougt1 Apologies for the error here. I have actually already reported this to the Azure team (Azure/azure-sdk-for-go#259) - they suggest that multiple NIC configurations are not supported so far. I will chase this up again and let you know Paul |
Hey @stack72, I think we can fix this. They are two I am going to take a look a this later to see if I can get it to work. (Probably not for 0.6.16) Thanks, |
No worries - this makes sense :) thanks for the work here on this P. |
Hi - just wondering if there has been any progress made on this? Thanks, |
Hi, Any update on this? Thanks! |
Hi Azure SDK for go team closed their case in August Azure/azure-rest-api-specs#305 Can this be progressed now so we can spin up dual homed VPN devices and firewalls on Azure. |
+1 |
Hi All, interested in this too. Certain instance levels of VMs support multiple NICs, but their docs state they must be added during time of VM creation. Doesn't seem to allow you to add a second NIC after the VM is already built. Thanks! |
I'm getting the same problem still on v.0.8. Has anyone found a workaround until this is added? |
@codyja Correct. We really need the code for this. I am on v0.8.4. |
Looks like I am reading this wrong. We need to set the primary during the CRP. I think what I might do is have it define the first one in the list of network_interface_ids as primary. Alternatively I could ask which was is primary. Not sure there is an existing configuration that we can copy an example of best implementation. I am open to suggestions. |
Stuff I learned. You can't rely on the order of the IDs passed to
|
If we go the network_profile {} TypeSet route what is the best approach towards handling the existing network_interface_ids? Keep it in for backwards compatibility ? Break older configs and upgrade code? network_profile is similar to the scale sets. Any thoughts? |
Here is a patch for consideration. https://github.com/pearcec/terraform/tree/azurerm-multi-network-interface-issue-6514 It is not ready for release.
Would appreciate a hashicorp person to offer up some advice. Thanks. |
@stack72 Hi Paul I thought I would draw your attention since you are with HashiCorp. |
@pearcec Hi Christian I am not entirely in favour of dropping I am however more in favour of something similar to your first idea, simply have the first item in the list get the Another fix/idea/thought I had in mind was to be able to pass on a dict instead of an id in the list, something more like:
In the first case, the primary property is simply undefined and the terraform behaviour stays as it is now (0.8.4). Either way, a fix for this is desirable. |
@smeeus Hi Sven Thanks for the idea. I tried the idea of setting primary based first one, but I couldn't guarantee the order when I tried. I thought about your idea of adding additional structure. I am not sure how to do that. But that seems like the most straightfoward path to keep backwards compatible. I also need to figure out do I have to test for the semantics of two primaries set as true? |
So I think for now I will try to go with
We can solicit further patches which check for validity of attaching a public interface to the primary and not sending in two primaries. The the AzureRM API will error out and give a sufficient error response. |
I keep wondering is this possible to code? How do I tell the Schema to look for a TypeList or a TypeSet? Any working examples in the code I can read? @stack72 Can you offer guidance here? |
@j00p34 A quick review of the code looks like a good fix. I like the solution of simply specifying the id (Why didn't I think of that?). Looks like we need some tests and some documentation. I am going to fetch the patch and run it myself to help approve. |
@j00p34 It works. I submitted a test and some documentation. Hopefully we can get this into v0.9.0 or v0.9.1. |
Can you create some type of device_id argument to set nic order? having undetermined order makes things a bit challenging during a deployment when you're expecting nics to arrive in one order and they arrive in another. |
@kblackstone What has your experience been? Is terraform not ordering it based on order in networkProfile? Do you know if Azure guarantees order when you make a rest call? Can you open this as a new issue? |
@pearcec other than the interface marked with primary_network_interface_id, the rest come in inconsistent order. I'm launching our firewall product (palo alto networks firewall) with 3 interfaces (sometimes we also use 4) to build out a customer demo environment and sometimes interface 2 and 3 are attaching to the vm inverted. in both the azurerm_network_interface order and the azurerm_virtual_machine > network_interface_ids section i have them in a specific order that is not being honored. if i do the same type of action using either an azure template or powershell scripting, the order matches the order in the script itself. i'll run the script again until the issue happens and then open a new issue with the evidence. side note: i'm educating our customers on the importance of automation when implementing the immutable infrastructure concepts and would like to pitch terraform as a viable option, but until this is resolved i can't do so without mentioning this caveat. to be fair i will also re-run this to be sure the error is not on my side. |
@kblackstone You can open an issue now. I have experienced it as well. I ignored the issue since we are using DHCP. Are you doing post automated post configuration work? At a minimum we plan to do rebuilds and use panorama to grab the existing configuration. having a different ordered interface would pose a problem. |
@pearcec I opened it about 15 minutes ago, #15133. I'm not doing automated post configure work in my demonstration builds for customers, but I expect/hope they will plan to. This issue would break that process exactly as you mention. Using DHCP is fine but then you try to push panorama policy it wouldn't match and would fail if the interfaces are out of expected order. |
@kblackstone please take another look at the issue you referenced. it doesn't look correct. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Terraform Version
v0.6.15
Affected Resource
azurerm_virtual_machine
Terraform Configuration Files
Error
* azurerm_virtual_machine.bastion_host: autorest:DoErrorUnlessStatusCode 400 PUT https://management.azure.com/subscriptions/e214ec76-5e8d-4923-8888-52758aede286/resourceGroups/azurebase/providers/Microsoft.Compute/virtualMachines/acctvm?api-version=2015-06-15 failed with 400 Bad Request
From Charles proxy
Expected Behavior
Create a VM with two NICs. However it would appear that the Primary property can't be set in Terraform or i can't find it in order to set it. Without it i cant see how i can create a VM with multiple NIC's.
The text was updated successfully, but these errors were encountered: