3

I have an existing Virtual Network (VN) set up in Azure. There is a VM on it. The VN is a basic network using the Azure DNS and was created with default settings (if memory serves).

I was able to configure a cloud service and add it to the VN via the Cloud.cscfg file, e.g. by adding:

  <NetworkConfiguration>
<VirtualNetworkSite name="Group Group-n xxxxxx" />
<AddressAssignments>
  <InstanceAddress roleName="yyyyy.API">
    <Subnets>
      <Subnet name="Subnet-42" />
    </Subnets>
  </InstanceAddress>
  <InstanceAddress roleName="yyyyy.WorkerRole">
    <Subnets>
      <Subnet name="Subnet-42" />
    </Subnets>
  </InstanceAddress>
</AddressAssignments>
</NetworkConfiguration>

where names have been changed to protect the innocent. Note that region name and affinity group were not supplied - I'm not sure if that is relevant.

I made similar adjustments to the cscfg files that we upload post-deploy and was able to update the configuration without causing problems.

The set up worked (for certain definitions of worked) and the web and worker roles in our cloud service were able to send messages over tcp to our VM on the same VN when using ip number addressing (It also sometimes worked when using the FQDN of the vm, but that's another issue that may result in another question).

That cloud service was a dev stack. To test that our deploy process works, I re-deployed that cloud service without the network configuration and confirmed that the roles were no longer listed on the subnet of the VN.

I then tried to add a different cloud service, in the same region, to the Virtual Network, using the same configuration.

That failed at deploy with the message "The deployment cannot use the VNNAME that belongs to a region azure".

I've done some searching and found little that helps, e.g. https://social.msdn.microsoft.com/Forums/en-US/68623f13-5acb-4cba-bb69-6c924e2786ef/the-deployment-cannot-use-the-virtualnetwork-that-belongs-to-a-region?forum=WAVirtualMachinesVirtualNetwork

describes a similar issue that hadn't received much in the way of useful advice.

So, the questions are, what are the correct steps to take when adding and removing an Azure Cloud service to an existing virtual network and is anybody aware of issues with Azure related to Virtual Network configuration that might be causing the above behaviour?

Thanks

PS I remembered some information that may be relevant. When the original cloud service was added to the VN, it was to the staging slot of a cloud service that did not have anything deployed to the production slot. In the second case, the service was being deployed to the staging slot of a service that had an occupied production slot with running web and worker roles.

  • I'm having the same issue, did you find any solution? – Mark Jan 9 '15 at 15:14
  • Not yet, but it dropped off my radar. I hope to get back to this soon and will provide an update, if I figure anything out. – Jeff Kramer Jan 14 '15 at 16:46
  • I found a solution in my case since then, details here: social.msdn.microsoft.com/Forums/azure/en-US/… – Mark Jan 14 '15 at 18:58
1

This question is so old that I forget many of the details. Nonetheless, someone in our office looked in to this. They didn't come across the same problem. I'd like to think it was because Azure was broken and now they've fixed it, but that's probably wrong.

This might not be the correct solution to my specific problem, but it at least serves as a suitable work-around for us and I thought I'd share it.

When working with a pre-defined Virtual Network and when trying to create a new entity (e.g. a virtual machine) on the Azure portal, my colleague noticed that in addition to being asked to provide a region to the new entity he could instead supply a virtual network name. He did so. He hasn't had any of the problems that I noticed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.