Our Classic VM in Azure has been off line a lot lately.
Resource Health shows an "Unavailable" status but claims no user interaction needed but to wait.
This has happened 2 times in the last 2 days. Waiting does not help. Restarting the VM does but that is taking longer and longer now. We know we have to migrate by March 2023 but now is not a good time.
• The classic VM resource health showing the state as unavailable means that the virtual machine is unavailable, and Azure is working to automatically recover your virtual machine and to determine the source of the problem. No additional action is required from you at this time. The health of this virtual machine may be impacted by an Azure service outage. Your virtual machine will automatically recover when the outage is resolved. It might also mean that we are currently unable to determine the reason for this downtime.
For more information regarding the resource health as ‘unavailable’, kindly refer the details given in the link below: -
https://learn.microsoft.com/en-us/azure/cloud-services/resource-health-for-cloud-services#what-does-it-mean-by-role-instance-being-unavailable
• Also, do ensure that you migrate your classic Azure VM managed through Azure Service Manager to the normal usual Azure VMs managed through Azure Resource Manager which is a replacement of the basic Azure Fabric software used for deploying Azure resources. Since, the management of these classic VMs is already deprecated and more than 90% of the VMs are normal ARM VMs, therefore, after 28th February 2020, you cannot deploy classic VMs, thus since this VM is created prior to that, it is facing maintenance issues since it must be taken down for managed OS updates, resource management through virtualization layer, etc. and others.
Thus, there is not much that you can do other than migrating these classic VMs to newer normal VMs managed by ARM. For more detailed information, kindly refer to the below link regarding this: -
https://learn.microsoft.com/en-us/azure/virtual-machines/classic-vm-deprecation
Related
In order to avoid doing some overhead work, I decide to use a work-around to upgrade my VM from server 2016 to 2019. The work around was successful and everything is running fine. One hiccup though is that I still see the plan being set to "2016-Datacenter".
(Correct me if I am wrong) So far doing some digging I see that this is set at the create time of the VM; it corresponds to the sku of the image used to build the VM.
My question is, are there any gotchas if the VM is running server 2019 but the plan is set to "2016-Datacenter"
Plan information is metadata Microsoft uses to track Marketplace offers. If you want to create an image in a shared gallery, using a source that was originally created from an Azure Marketplace image like this, you may need to keep track of purchase plan information. You may face issues when you create a VM from the Azure Marketplace image if there is wrong plan information. Read here for more details.
We are able to do an Azure VM in-place upgrade to Windows Server 2019. Here is the step by step process to update the IaaS VM Windows server to Windows Server 2019 for your reference.
However, it's not recommended to do because Microsoft does not support an upgrade of the operating system of an Azure VM.. It prefers to use a clean uninstallation and installation. To work around this issue, create an Azure VM that's running a supported version of an operating system, and then migrate the workload.
If you have a Virtual Machine you are required to apply patches every Patch Tuesday and ensure the OS is up to date to prevent security issues.
If you get a PAAS Azure WebApp do Microsoft take care of patching the underlying OS?
If so would you see downtime when this happens? Or are all the apps on that Host OS moved to another Host in some way?
For the first question, that is kind of the point of PaaS. Azure takes care of the patches for the OS.
As for an answer to your other questions, this GitHub issue is quite good: https://github.com/Azure/app-service-announcements/issues/63.
Most updates can be performed without affecting your services running on the platform’s infrastructure. For this update, you’ll notice a restart of your web apps, the same that takes place during our regular monthly OS update. Our goal is to avoid service interruptions and, as with every upgrade to the service, we will be monitoring the health of the platform during the rollout.
Your apps are moved to another update domain transparently while the patch is applied to the update domain that hosted your app. It does cause an app restart of course.
Take a look a the blog we just published describing what goes on behind App Service updates - https://blogs.msdn.microsoft.com/appserviceteam/2018/01/18/demystifying-the-magic-behind-app-service-os-updates/
I am new to the Azure platform and hosting in general and I am currently moving some web apps to Azure Paas and have configured a single App Service Plan which contains 3 applications.
I have read all the documentation I can find and I know the plan guarantees 99.95% up time but I cant find any info in regard to hardware failures. i.e. if there is a hardware failure on a rack where my app is hosted am I automatically covered by the plan? Does my app exist in multiple fault domains?
Hope someone can help
Thanks
You can see the details here. I'd say hardware failures are considered as downtime:
https://azure.microsoft.com/en-us/support/legal/sla/app-service/v1_4/
Microsoft guarantee that Apps running in a customer subscription will be available 99.95% of the time.
Note: No SLA is provided for Apps under either the Free or Shared tiers.
For more information, refer SLA for App Service.
This SLA works based on the fault domain and update domains, understand how fault domains and update domains works in Azure.
As you can tell from the title, I set up a virtual machine on Azure and installed a website and database that my company is hosting for a client. The spending limit was not lifted, and after it was reached my VM was deleted.
Since that time I have lifted the spending limit, but I have no idea how to get the VM back, or if that is possible at all. What are the steps I need to take in order to get back to where it was? Is the database that was on this server gone for good? I spent hours getting this server up to date with updates and Web Platform Installer software. This would be rather cruel if everything is now lost.
Are you sure the VM was actually deleted, or was the deployment deleted? Check in the portal under the Virtual Machines tab. Look under the Disks section and see if you have a disk there that represents the server that was running.
If so, you should be able to create a new Virtual Machine instance by using the New button at the bottom of the portal. Click on the New button and select Compute > Virtual Machine > From Gallery. Then click on the My Disks under the popup screen. This will let you select the disk that represents the OS disk from your server.
You may also want to check to see if the Cloud Service container that was running the server was also deleted. When you create a Virtual Machine a Cloud service is created to act like a container for that machine instance. You can also add additional machines to that same container. Take a look under Cloud Services in the portal and see if one is there named like what you had setup for the virtual machine. If so, then you'll either have to delete this one so you can reuse the name, or you can user the PowerShell cmdlets to start the virtual machine and put it into the already existing cloud services container.
I had the same experience. Our Azure Virtual machine was gone, and I got really scared when it was also missing from the management portal. I solved it like this.
Remove the spending limit on the credit card from the Azure account portal.
Delete the cloudservice that had the same name as the VM. The cloud service was only an empty container now that the VM was gone.
It is easy to restore the missing VM by creating a new Virtual Machine. Choose to create a new VM from Gallery, and under the Gallery you can find your missing machines harddisk under "My disks".
Wait while the machine is restored, and then start it.
Now you have to manually recreate all network endpoints. That was a pain as I had quite a few different streaming servers installed.
I wish that Azure only stopped an virtual machine instead of silently removing it when the customer fails to pay. Especially because it is quite hard to understand which services are free, which services are free trials and which services that you must pay for.
Let's say I have 3 instances in the Azure. Each is running separate layer of the application, as I described in this question Independent deployment of separate layers to Azure. For independent deployment of each layer (read Role) a separate Azure deployment project is created. The question is, what instance will be replaced, when I will be deploying, for example business layer? Can I be sure that the instances with UI and Data Access will stay untouched? How the instance to be replaced is found, based on name of the role?
To clarify, you have 3 layers, each hosted in a different windows azure role (not instance). If you have each role in a seperate deployment (seperate hosted services), then when you deploy, you are only going to be upgrading that layer. The other layers will not be impacted.
However if there are any signature differences, a dependent layer may break if the service its trying to call changes. Its for this reason that you want t omake sure any services support versioning and are always backwards compatible at least one version.
I've created a quick blog post with some screen shots of doing a single role upgrade. Note that the silverlight portal issued an exception for me while doing this and I've reported that error and will update the blog post if we find out what it was about.
Updated: There is bug in the silverlight management portal that currently prevents the performance of a single role upgrade. The Windows Azure team is aware of this and will be addressing it in a future update. No ETA for that update at this time. However, you can still perform the single role update/upgrade via the management API.
As Brent said, it is definitely possible to do a Single Role upgrade. It used to be that if you made any changes to the ServiceDefinition (change VM size, added new Config settings, updated Role Name or changed the instance count from the service definition that is currently deployed) when you upgraded that role, Azure Fabric Controller would not allow you to do in-place upgrade. Now, that is also possible. So you can do an in-place upgrade on Role and bump up the VM size. As always, you at least want to have 2 instances to ensure that you don't experience any downtime.
Ranjith
http://www.opstera.com