When I create a VM in Azure, it is creating an accompanying Cloud Service and Network Resource. I found that the Cloud Service is there as a deployment layer. I have not found why the Network Interface is there.
Since this particular circumstance is not going to have a deployment associated with it as it is used as an Elasticsearch server, I technically will not be needing the Cloud Service. However, when I delete the service, it takes the VM with it even though I do not expressly select it for delete.
My two specific questions:
1st - Why is there a Cloud Service created and not able to be deleted without repercussions when there is not deployment necessary?
2nd - Why is the Network Interface created and not able to be deleted without repercussions?
Both questions are with the understanding that this is an Elasticsearch VM.
A cloud service is a required artefact of an ASM/classic deployment if a VM. It is not needed in an Azure Resource Manager deployment, which is what you should use for new deployments. However, the two types of deployment are orthogonal, so you may need to keep using ASM if you already have VMs deployed that way. If so, you should consider migrating them to ARM.
Related
Suddenly since a couple of days ago I cannot deploy to my Azure cloud service to the staging environment. Deployment fails with:
Allocation failed; unable to satisfy constraints in request. The requested new service deployment is bound to an Affinity Group, or it targets a Virtual Network, or there is an existing deployment under this hosted service. Any of these conditions constrains the new deployment to specific Azure resources. Please retry later or try reducing the VM size or number of role instances. Alternatively, if possible, remove the aforementioned constraints or try deploying to a different region.
I do have my database virtual machine, my web-/workerroles and my Azure Storage account in the same affinity group talking to each other via a virtual network and I believe it is important to keep it that way to minimize network latency. Has anyone experienced this problem and could you solve it without getting rid of the affinity group?
I want to understand how does this Web / Worker role under cloud service work. As per my understanding, we have to define the required Web / Worker role instance count in CSDEF file, and Azure will create VMs (Instances) under the cloud service automatically. How about the application is updated and new code is deployed? Will the existing instances destroyed and new instances will be created or only the changed code will be updated in IIS? How does it work in the backend?
Note: Basically I have four instances in a web role and I want to create around 20 local user accounts in the VMs to manage it by different teams. I want to ensure the accounts do not get deleted whenever deployment is done.
Basically I have four instances in a web role and I want to create
around 20 local user accounts in the VMs to manage it by different
teams. I want to ensure the accounts do not get deleted whenever
deployment is done.
Simple answer: Don't Do This!
Azure Cloud Services are essentially Stateless Virtual Machines. What that means is that anything you do in the VM (like installing software etc.) after a VM is created for you can be removed. Though this doesn't apply when you simply deploy the new version of the code but there are times when Microsoft takes down faulty VMs and stand up new VMs for you automatically from the last package file you used to create/update the deployment. In this scenario, any changes you have made will be lost.
Cloud services should be considered stateless. The disks won't necessarily be destroyed on every deployment, but you must plan for it. Any configuration or operations you wish to perform prior to the role starting up must be defined as a startup task in the CSDEF file.
I have run the powershell script for creating azure VM. An error occurs "Cannot find VM current status" when another user too creates VM in the same cloudservice. How to resolve this issue. Thanks in advance.
Azure has two different deployment models for creating and working with resources: Resource Manager (the new one) and Classic (the old one). It is transitioning from classic to Resource Manager.
You are using Cloud Services, which exist only with the classic deployment model. One of the problem with classic is the fact that most operations on your resources cannot be paralyzed.
When you edit the state of a cloud service, it won't accept any other operations until the first one is done.
Microsoft recommends that most new deployments use the Resource Manager model.
If you can, you should consider to migrate to the new model.
Please see:
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-azurerm-versus-azuresm/
https://azure.microsoft.com/en-us/documentation/articles/resource-group-overview/
https://azure.microsoft.com/en-us/documentation/articles/powershell-azure-resource-manager
https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-azure-manage-vm-asm-arm/
I am having an issue deploying to the Staging environment of my Windows Azure Cloud Service.
This is something I do frequently without issue before doing a swap to Production (once I have validated everything is OK in Staging). Today for some reason I am getting this error when trying to deploy:
Allocation failed; unable to satisfy constraints in request. The requested new service deployment is bound to an Affinity Group, or it targets a Virtual Network, or there is an existing deployment under this hosted service. Any of these conditions constrains the new deployment to specific Azure resources. Please retry later or try reducing the VM size or number of role instances. Alternatively, if possible, remove the aforementioned constraints or try deploying to a different region. The long running operation tracking ID was: da5cc14aaba6228683cb4e8888b835e1.
Seeing as my deployment package has not changed since the last time I successfully performed an update of my Staging environment (apart from one line of code for a bug fix) I can't see this being an issue with my package. I am hoping this is transient Azure environment issue - anyone any ideas as to what this may be?
There is a fragmentation issue in the cluster you are trying to deploy to. The ops team is engaged and working to resolve and you should be able to deploy again later tonight or tomorrow.
Some additional information:
Once you create a deployment (either prod or staging slot) in a cloud service your entire cloud service (both prod and staging slots) are pinned to a cluster of machines (there are some Mark Russinovich fabric videos with more details if you are interested). So if there is a problem in a cluster, or you try to deploy a VM size not available in the cluster such as the new D series machines, then you may fail if the specific cluster can't allocate the request. To resolve this you can deploy to a brand new cloud service which will allow the fabric to check all clusters in that datacenter/region to satisfy the allocation request.
Consider a different upgrade strategy for scenarios like this. A lot of services will upgrade by creating a new deployment in a new cloud service, thus getting a new URL and IP address, and then modify the CNAME or A Record in order to transition clients to the new service.
If you see this issue again you can usually get a fast resolution by opening a support incident - http://azure.microsoft.com/en-us/support/options/
Update: We have a new blog post that describes this scenario and the common causes - http://azure.microsoft.com/blog/2015/03/19/allocation-failure-and-remediation/.
We had a similar allocation failed issue recently deploying our Azure Cloud Service:
Azure Cloud Service Deployment Error
Allocation failed; unable to satisfy constraints in request. The requested new service deployment is bound to an Affinity Group, or it targets a Virtual Network, or there is an existing deployment under this hosted service. Any of these conditions constrains the new deployment to specific Azure resources. Please retry later or try reducing the VM size or number of role instances. Alternatively, if possible, remove the aforementioned constraints or try deploying to a different region.
Allocation Failed - Resolution
Delete Existing Cloud Service
Create New Cloud Service target different Data Center or Resource Group (upload SSL certs required)
Redeploy cloud service package
Relink VSO Team Projects
I suspect the issue has something to do with a corrupt resource group or recent Azure upgrades that were not backwards compatible with older resource groups.
So I am a little bit confused about the Azure feature to create virtual machines(i.e VMRoles).
When I do a quick create via the managment portal, I am not asked to specify nor a hosted service nor a storage account. After I click 'create' I see that a storage account is generated for me automatically with some unique name, but I don't see the same for a hosted service. Is a hosted service not needed to create a VM?
The thing that is confusing is that it seems like every other method for creating a VM does require me to specify a hosted service (Azure PowerShell, REST API). And indeed after I create the VM using one of these methods I see my VM inside the hosted service...
Anyone can explain this?
Thanks in advance
Please do not confuse Windows Azure Virtual Machines (IaaS, stateful) with Windows Azure VMRole (PaaS, stateless).
As for creation - the process behind the portal is automated. For me, I have a separate Cloud Service for each Virtual Machine I've created (along with the auto generated storage account). However as all operations are asyc, and I also guess the Microsoft teams are using some kind of CQRS pattern behind the portal, it might take some time for all the components behind a Virtual Machine to appear. While the API strictly requires everything to be ready set, before you actually create the Virtual Machine. My guess is that soon you will also see a cloud service created for your VM (it usually is with the name of the Virtual Machine you created). Also, if you have noticed, the public URI for accessing your Virtual Machine (be it RDP or SSH) has the format of [your_vm_name].cloudapp.net - so this is a Cloud Service (formerly known as Hosted Service).
First of all Windows Azure Virtual Machines and VM Role are two separate things. Based on what you have explained it seems you are trying to create a Windows Azure Virtual Machine so I will explain you in short how it works:
Very first: In order to create a Windows Azure Virtual Machine you need a VHD which has OS Image. You can use one from Gallery or you can upload one by yourself to your specific Blob Azure Storage.
When you use Quick create or create the process is exactly same in the background however during quick create lots of settings is already predefined as will quick create you will only get Windows OS VHD to choose. In both cases a storage account is used to copy the OS VHD (if it is not part of your OS image collection). In most of the cases a previously created storage account is used, so you may think in was not created but in fact the storage account was used to copy the VHD from repo. This may not be the case if you create a VM from an image which is already in your OS VHD collection.
With quick create the DNS name you set is become the VM name but with create you have option to create a different DNS name for your application but they needed in both cases. In any case the DNS name will bind to your VM, the same DNS name will distinguish your VM from others and a must to configure for any VM.
I believe that the cloud service is not surfaced for a single quick-create Virtual Machine. This is to make Virtual Machines as easy to use as possible. The cloud service would be created and be displayed on the portal were a second virtual machine to be added to the cloud service.