I have a cloud service and a storage account deployed using the classic resource manager in the East US region; there is also a classic backup vault in the West Europe region.
Due to high latency, I want to move all of these resources to the UK South region, which is the closest one to me and others using these services. I have created a new resource group in the UK South region, however, when I try to move my existing classic resources to the new resource group, it says:
Classic resources must be moved separately and aren't displayed below.
Reading the article it linked to, it says that to move classic resources when experiencing this limitation, I need to contact support to have this operation done manually.
I do not have a support plan and am hoping not to buy one for this single task. Is there any other way around this limitation?
I think that you can walk around it by:
1. Create a new blank cloud service in your new resource group in UK South region.
2. Modify the deployment process to deploy the code to the newly created cloud service.
I hope this helps.
As you mentioned that it is limited by Azure. The following is snippet from the official document.
When moving resources from one resource group to another resource group within the same subscription, the following restrictions apply:
Virtual networks (classic) cannot be moved.
Virtual machines (classic) must be moved with the cloud service.
Cloud service can only be moved when the move includes all its virtual machines.
Only one cloud service can be moved at a time.
Only one storage account (classic) can be moved at a time.
Storage account (classic) cannot be moved in the same operation with a virtual machine or a cloud service.
As Toan nguyen mentioned that we need to redeploy it if you don't want to call Azure Support.
Related
we have problem to move Cloud Service (Extended Support) from 1 resource group to another resource group in the same subscription. Both resource groups are in the same location.
Picture with status of the move validation
Error code in validation window is:
{ "code": "ResourceMoveNotSupported", "target": "/subscriptions/123456-xxxx-yyyy-zzzz-123456/resourceGroups/AAAAA-BBBBB-Migrated/providers/Microsoft.Compute/cloudServices/AAAAA-BBBBB",
"message": "Resource move is not supported for resource types
'Microsoft.Compute/cloudServices'." }
Additional information:
Source resource group was created automatically after successful in-place migration from Cloud Service (Classic) to Cloud Service (Extended Support). Now we need to move all resources created by migration back to the original resource group, where Cloud Service (Classic) was previously located. Cloud Service (Classic) was automatically deleted after migration.
The main reason why we migrated from Cloud Service (Classic) to Cloud Service (Extended Support) was ability to move between subscriptions, but we are unable to move it even inside the same subscription :(
Any ideas how to proceed with this problem?
Best course of action is to create an Azure Support Ticket.
These type of operations are deep internal to azure, and reasons why these fail range from config errors, failed internal transactions to straight up bugs for a scenario they did not consider.
Note: it might take some time and patience on your side to get the desired results reached from Azure support, as these type of tickets are usually low priority.
We finally managed to contact Azure Support.
This move is not supported :(
Since the Cloud Service extended support is a new published product,
we are sorry that currently it does not support migration from one
subscription to another. We are sorry that moving “Cloud Service
extended support” among resource groups in the same subscription is
also unsupported.
Since yesterday, I'm trying to create new VM and I'm not able because the majority of the sizes are not available for my region, West Europe. Using Azure Portal I get all D series greyed:
I tried Azure Reservations with same result:
I suppose there are issues in this and another regions.
But then I tried to get availability using CLI tool az, following this reference. The, executing referenced command I get this list of available sizes:
It seems contradictory information, because I see some D series VM.
May it be that they are available in general, not taking into account current occupation?
Is there any az command to get actual available sizes in my region?
Da/Das series VMs use AMD CPU. However, based on my test, they are not available in location West Europe.
The normal D series VM should be available in West Europe. There are several reasons which may prevent you from choosing it:
You have reached your CPU resource limitation in that region. To solve this, you may request an increase in CPU quota limits per Azure VM series
Some Azure subscriptions (trial, MSDN developer, student trial and so on) can only create limited resources in limited locations. To solve this, you may update your subscription to a pay-as-you-go one.
Other reasons. You may directly contact the Azure Support team by submitting a support request on the Azure portal.
I've just checked my current Azure usage, and I'm seeing an item called...
Premium Storage - Page Blob/P10 (Units) - US West
This item is quite expensive, but I don't know what it is, or how it's been allocated, or how to remove it.
I've checked my storage accounts, vm's, and databases, and confirmed that they're all in Australia.
This is the first time I've noticed this "US West" storage item.
The only new thing I've added to Azure recently is an "S0 Standard (10 DTUs)" database account. However this says it's located in Australia, and it currently has nothing in it. I've checked the resource cost, and it's currently showing $0.
How do I go about figuring out what this mystery storage resource is?
I think I've traced it. It's the disk for one of my VM's. I don't know why the location for the storage is "US West", when the location for the VM is Australia. The VM was created as an experiment and isn't currently being used. I was testing out the new ARM deployment type. My fault for not fully understanding the pricing before creating the resource. I assumed storage cost would be negligible, and that the VM wouldn't cost much if it was deallocated most of the time. Anyway I'll delete the VM, and do more reading about pricing before trying it again.
I have a webservice which uploads data to blob store. I have 2 deployments of this webservice, on in south east asia and one in US. Each deployment has a different storage account associated with it(while creating a cloud service you can associate a storage account with it), say StorageSEA and StorageUS.
As of now, I read the storage account connection string from the config, which means that when I deploy to southeast asia I have to go and update the connection string to point to StorageSEA and change it to StorageUS when publishing to US. This doesn't seem like a approach I will be able to sustain in future, as I plan to go ahead with more deployments.
So I was wondering if there was a way to get the associated storage account instead of updating the config file for each deployment.
There are two solutions I could think of:
Use config transformation to create 2 separate deployment configuration files - one for South East Asia and other one for US. Each config file will have storage account for that data center.
Programmatically identify the deployment location - In this case, you would define both storage account connection string in your configuration file. When the role starts up, you would find the data center location of the cloud service and based on that you pick up one of the values. For this to work, you would need to implement Service Management API's Get Hosted Service Properties operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460806.aspx).
I've created a Hosted Service that talks to a Storage Account in Azure. Both have their regions set to Anywhere US but looking at the bills for the last couple of months I've found that I'm being charged for communication between the two as one is in North-Central US and the other South-Central US.
Am I correct in thinking there would be no charge if they were both hosted in the same sub-region?
If so, is it possible to move one of them and how do I go about doing it? I can't see anywhere in the Management Portal that allows me to do this.
Thanks in advance.
Adding to what astaykov said: My advice is to always select a specific region, even if you don't use affinity groups. You'll now be assured that your storage and services are in the same data center and you won't incur outbound bandwidth charges.
There isn't a way to move a storage account; you'll need to either transfer your data (and incur bandwidth costs), or re-deploy your hosted service to the region currently hosting your data (no bandwidth costs). To minimize downtime if your site is live, you can push your new hosted service up (to a new .cloudapp.net name), then change your DNS information to point to the new hosted service.
EDIT 5/23/2012 - If you re-visit the portal and create a new storage account or hosted service, you'll notice that the Anywhere options are no longer available. This doesn't impact existing accounts (although they'll now be shown at their current subregion).
In order to avoid such charges the best guideline is to use Affinity Groups. You define affinity group once, and then choose it when creating new storage account or hosted service. You can still have the Affinity Group in "Anywhere US", but as long as both the storage account and the hosted service are in the same affinity group, they will be placed in one DataCenter.
As for moving account from one region to another - I don't think it is possible. You might have to create a new account and migrate the data if required. You can use some 3rd party tool as Cerebrata's Cloud Storage Studio to first export your data and then import it into the new account.
Don't forget - use affinity groups! This is the way to make 100% sure there will no be traffic charges between Compute, Storage, SQL Azure.