chef/knife-azure

Error when creating VM in ARM mode and specifying vnet

Closed this issue · 9 comments

matkam commented

I'm trying to create a VM in an existing subnet and getting the following error:

$ knife azurerm server create --azure-resource-group-name AzureToAws --azure-vnet-name AzureToAws --azure-vnet-subnet-name default --azure-vm-name matttest105 --azure-service-location westus --azure-image-os-type ubuntu --ssh-user ubuntu --ssh-password Test123! -VV
INFO: Using configuration from /Users/matt/.chef/knife.rb
WARN: Azurerm subcommands are experimental and of alpha quality. Not suitable for production use. Please use ASM subcommands for production.
WARN: Azurerm subcommands are experimental and of alpha quality. Not suitable for production use. Please use ASM subcommands for production.
INFO:Resource Group AzureToAws already exist. Skipping its creation.
INFO:Adding new VM matttest105 to this resource group.
Creating Virtual Machine....
ERROR: At least one resource deployment operation failed. Please list deployment operations for details. Please see http://aka.ms/arm-debug for usage details.
DEBUG: /Users/matt/.chefdk/gem/ruby/2.1.0/gems/ms_rest_azure-0.2.3/lib/ms_rest_azure/azure_service_client.rb:72:in `get_long_running_operation_result'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/ms_rest_azure-0.2.3/lib/ms_rest_azure/azure_service_client.rb:85:in `get_put_operation_result'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/azure_mgmt_resources-0.2.1/lib/azure_mgmt_resources/deployments.rb:188:in `block in create_or_update'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/promise.rb:497:in `call'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/promise.rb:497:in `block in on_fulfill'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/safe_task_executor.rb:24:in `call'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/safe_task_executor.rb:24:in `block in execute'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `block in synchronize'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/safe_task_executor.rb:19:in `execute'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/promise.rb:527:in `block in realize'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:348:in `call'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:348:in `run_task'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:337:in `block (3 levels) in create_worker'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:320:in `loop'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:320:in `block (2 levels) in create_worker'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:319:in `catch'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:319:in `block in create_worker'
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/logging-2.0.0/lib/logging/diagnostic_context.rb:448:in `call'
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/logging-2.0.0/lib/logging/diagnostic_context.rb:448:in `block in create_with_logging_context'
Vasu1105 commented

@matkam - Thank you. We will be looking into it.

Vasu1105 commented

@mattkam Could you please pull the latest changes from the 'master' and check that does the issue still exists ?

matkam commented

@Vasu1105 The storage and public IP address get created, but then I get this error:

$ knife azurerm server create --azure-resource-group-name AzureToAws --azure-vnet-name AzureToAws --azure-vnet-subnet-name default --azure-vm-name matttest111 --azure-service-location westus --azure-image-os-type ubuntu --ssh-user ubuntu --ssh-password Test123! -VV
INFO: Using configuration from /Users/matt/.chef/knife.rb
WARN: Azurerm subcommands are experimental and of alpha quality. Not suitable for production use. Please use ASM subcommands for production.
WARN: Azurerm subcommands are experimental and of alpha quality. Not suitable for production use. Please use ASM subcommands for production.
INFO:Resource Group AzureToAws already exist. Skipping its creation.
INFO:Adding new VM matttest111 to this resource group.
Creating Virtual Machine....
ERROR: {"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.","details":[{"code":"BadRequest","message":"{\r\n  \"error\": {\r\n    \"code\": \"InUseSubnetCannotBeDeleted\",\r\n    \"message\": \"Subnet GatewaySubnet is in use by /subscriptions/xxx/resourceGroups/AzureToAws/providers/Microsoft.Network/virtualNetworkGateways/AzureToAwsGateway/ipConfigurations/default and cannot be deleted.\",\r\n    \"details\": []\r\n  }\r\n}"}]}}
DEBUG: /Users/matt/.chefdk/gem/ruby/2.1.0/gems/ms_rest_azure-0.2.3/lib/ms_rest_azure/azure_service_client.rb:72:in `get_long_running_operation_result'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/ms_rest_azure-0.2.3/lib/ms_rest_azure/azure_service_client.rb:85:in `get_put_operation_result'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/azure_mgmt_resources-0.2.1/lib/azure_mgmt_resources/deployments.rb:188:in `block in create_or_update'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/promise.rb:497:in `call'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/promise.rb:497:in `block in on_fulfill'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/safe_task_executor.rb:24:in `call'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/safe_task_executor.rb:24:in `block in execute'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `block in synchronize'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/safe_task_executor.rb:19:in `execute'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/promise.rb:527:in `block in realize'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:348:in `call'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:348:in `run_task'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:337:in `block (3 levels) in create_worker'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:320:in `loop'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:320:in `block (2 levels) in create_worker'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:319:in `catch'
/Users/matt/.chefdk/gem/ruby/2.1.0/gems/concurrent-ruby-1.0.2/lib/concurrent/executor/ruby_thread_pool_executor.rb:319:in `block in create_worker'
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/logging-2.0.0/lib/logging/diagnostic_context.rb:448:in `call'
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/logging-2.0.0/lib/logging/diagnostic_context.rb:448:in `block in create_with_logging_context'

Deployment history shows:

Subnet GatewaySubnet is in use by /subscriptions/xxx/resourceGroups/AzureToAws/providers/Microsoft.Network/virtualNetworkGateways/AzureToAwsGateway/ipConfigurations/default and cannot be deleted. (Code: InUseSubnetCannotBeDeleted)
Vasu1105 commented

@matkam I tried to reproduce this issue what I did is I created the vnet 'vj-net' and default subnet in it on azure portal. Then I have created one VM using existing vnet and subnet. I ran following command and VM got created successfully.
$ knife azurerm server create --azure-resource-group-name 'vj-rgp' --azure-vm-name 'vj-vnet-test' --azure-service-location 'westus' --azure-image-os-type 'ubuntu' -x azure -P azure@123 -r 'recipe[getting-started]' -c ~/workspace/chef-repo/.chef/knife.rb --azure-vnet-name vj-net --azure-vnet-subnet-name default -VV

Then I have created another VM using the same vnet and subnet using following command. This also worked fine

$ knife azurerm server create --azure-resource-group-name 'vj-rgp' --azure-vm-name 'vj-vnet-test1' --azure-service-location 'westus' --azure-image-os-type 'ubuntu' -x azure -P azure@123 -r 'recipe[getting-started]' -c ~/workspace/chef-repo/.chef/knife.rb --azure-vnet-name vj-net --azure-vnet-subnet-name default -VV

Looking at the error it seems to be something wrong on the vnet and subnet settings. And this error is raised from azure API's and not something related to knife-azure. So I think you need to check if vnet and subnet settings are correct.

matkam commented

@Vasu1105 In addition to creating a default subnet like you did, I created a "GatewaySubnet" as per the link below, and I think this is where there is confusion. It seems like knife-azure is trying to delete it?

Here are the instructions I used to create my network on Azure: https://blogs.technet.microsoft.com/canitpro/2016/01/11/step-by-step-connect-your-aws-and-azure-environments-with-a-vpn-tunnel/

Vasu1105 commented

Ok @matkam. We will check what is the root cause of this issue. We are creating the vm using template so we have to check the behavior of above case. We will update you once we have more details on this issue.

Aliasgar16 commented

@matkam I have successfully reproduced the issue using the subnet other than the default subnet and also non-gateway subnet. Will get back to you soon with the fix.

  • ❤️1
Aliasgar16 commented

@matkam PR with fix for the above issue.

matkam commented

Just tried the latest from master, and it looks to be working now. Cheers.