Question about az vm create.
It appears that when using an existing NIC, the accelerated networking settings of that NIC override the accelerated networking setting specified when creating the VM.
i.e. if you create a NIC with accelerated networking disabled and then use that NIC to create a VM that would otherwise have the setting enabled, the VM is created with the setting disabled.
This specification probably makes the most sense, but if you can confirm that is intentional, can we add language to the --accelerated-networking option to clarify that the setting of any preexisting NIC takes precedence?
--accelerated-networking
Enable accelerated networking. Unless specified, CLI will enable it based on machine image and size.
accepted values: false, true
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@adewaleo could you please respond to Dillon's question?
@dcbrown16 my apologies for the late response. According to this doc, a vm (and its nic) can be updated to support accelerated networking.
Given this is possible, vm create should be able to enable accelerated networking on the existing nic, when --accelerated-networking is set to True.
I should be able to update this in an upcoming sprint.
@adewaleo sorry, are you updating the command to work that way or updating the document?
Just to be clear, I have a customer report that setting --accelerated-networking to true is not honored if an existing NIC with accelerated networking disabled is specified. If the intended specification is to have the NIC switch to enabled in that case, please verify on your end or contact me at v-dibr internally if we need offline follow-up.
See #9496 also, there is some confusion as to why creating the NIC explicitly leaves accelerated networking disabled but creating it implicitly while creating a VM supposedly enables it.
CC @KeiroKamioka0000
@adewaleo
Hello, any information would be appreciated regarding about this question.
@KeiroKamioka0000, I followed up on the thread.
@dcbrown16 sorry if I was not clear. The goal will be to update the nic or at least fail and inform the user that the supplied nic doesn't have the correct setting.
@adewaleo did this change ever get made? It looks like it was pushed through a few sprints and dropped.
Our customer is now asking for an update.
Hello @dcbrown16, I apologize that I didn't got to follow up on this issue due to other work / issues on my plate when the cli was transitioning owners. I am no longer on the CLI team.
Hopefully @yonzhan and @qwordy can follow up on this issue.
@qwordy please take a look and comment.
I check the Azure CLI code.
If using an existing NIC, Azure CLI will ignore accelerated_networking setting.
Azure CLI forbids passing nsg, public_ip_address, subnet, vnet_name, application_security_groups when using an existing NIC. If any of them is given, an error raises: "When specifying an existing NIC, do not specify NSG, public IP, ASGs, VNet or subnet."
So the current design is "Just use the exising NIC. Don't change the NIC settings in vm create. If you want to udpate NIC, use nic command".
I think maybe I can add accelerated_networking to the forbidden list.
What's your idea? @achandmsft @yugangw-msft
I check the Azure CLI code.
If using an existing NIC, Azure CLI will ignore accelerated_networking setting.
Azure CLI forbids passingnsg, public_ip_address, subnet, vnet_name, application_security_groupswhen using an existing NIC. If any of them is given, an error raises: "When specifying an existing NIC, do not specify NSG, public IP, ASGs, VNet or subnet."
So the current design is "Just use the exising NIC. Don't change the NIC settings invm create. If you want to udpate NIC, useniccommand".
I think maybe I can add accelerated_networking to the forbidden list.
What's your idea? @achandmsft @yugangw-msft
Forbidding --accelerated-networking if an existing nic is used, doesn't sound like a bad idea. However, that might be extreme or a breaking change. A warning might be gentler. That being said if this is not doing what the user intends then maybe failing is okay.
I will leave it to you all to decide between, warning, error / failure, or updating the nic within vm create.
Thanks! Agree. Maybe we can use a warning first, then change warning to error later (like after 6 months) in order to be consistent with existing behavior shown in the code below. But we can give users some time to be used to new behavior.
raise CLIError('When specifying an existing NIC, do not specify NSG, '
'public IP, ASGs, VNet or subnet')
The fix will be released at milestone S160. Official Release time: 11/04/2019.
My PR #10832 has been merged. If you still have issues, you can reopen and comment. Thanks.
Hi, after running the following az vm create on az version 2.7.0, I still see the warning "When specifying an existing NIC, do not specify accelerated networking. Ignore --accelerated-networking now. This will trigger an error instead of a warning in future releases." even though the command I'm giving doesn't specify --accelerated-networking.
az vm create \
--location westus2 \
--resource-group myResourceGroup \
--name myVM1 \
--image Canonical:UbuntuServer:16.04-LTS:latest \
--size Standard_D32_v3 \
--admin-username azureuser \
--generate-ssh-keys \
--nics myNic 2>&1
I've copied setup steps directly from https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-cli. Is this expected? I'd like to ensure that this doesn't surface as an error later.
Most helpful comment
@KeiroKamioka0000, I followed up on the thread.
@dcbrown16 sorry if I was not clear. The goal will be to update the nic or at least fail and inform the user that the supplied nic doesn't have the correct setting.