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?
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.