This isn't correct.

Azure uses HyperV[1] as their virtualization technology. That isn't the same as Windows at all, although it is included in Windows Server.

While I have had more reboots on Azure than on AWS, it isn't weekly by any means - more like every 3 months or so. It hasn't been often enough for it to be a problem (low usage environment though, so YMMV).

[1] http://en.wikipedia.org/wiki/Hyper-V#Microsoft_Hyper-V_Serve...

Yes, Azure VMs run on top of Hyper-V. Which means that the physical machine must reboot after every Hyper-V update.

However, each physical machine also runs an Azure Host Agent, which runs on top of Windows Server Core. While the use of Server Core helps cut down on reboots, it doesn't eliminate them.

But then, why doesn't Hyper-V just stay up while it reboots the VM containing the Host Agent? Because the virtual disk drivers are implemented for Windows Server. (Hyper-V has the concept of a management OS, which has privileged access to the hardware.)

Source: http://blogs.technet.com/b/markrussinovich/archive/2012/08/2...

Interesting.

That's a pretty serious disadvantage over VMWare.

But I guess the limited attack area of Windows Server Core means many people can avoid applying patches much of the time.

As the underdog competing against ESX, Microsoft had to make it easy for businesses to adopt Hyper-V.

By hooking up Hyper-V to the Windows management OS, they get to leverage Windows device drivers. And this, in turn, ensures broader hardware compatibility.

Of course, this goal became unnecessary for Azure, where Microsoft controls the hardware. But Hyper-V had already been designed that way.

Certainly, Server Core is pretty stripped-down. The Russinovich blog says they reboot about once a month, but the Azure support blog says they reboot every 2-3 months.

http://blogs.msdn.com/b/wats/archive/2013/09/24/windows-azur...

Awww.

"When this occurs, you loose connectivity..."

"While this type of proactive notification of planned maintenance is not currently provided, we encourage you to provide comments on this topic so we can take the feedback to the product teams."

Wow. They didn't notify at one point?

In my experience (running a Windows vm) the forced reboot is more like every two months. Also they have a feature called availability sets where you can load balance two VMs and they guarantee that one of them will always be up.

Edit: Looking back at my email history, it's much less often than that. The interval between the previous two reboots was 6 months. They also gave about two weeks notice when it happened.

But in order to use Availability Sets, you MUST use their load-balancer thingy and share a single IP address. Meaning if you want to individually address each server, you've gotta get creative with port mapping. It's very annoying.

I just had this happen recently and there was no warning. Perhaps it depends on the "level" of services you are using. My instance was just an "extra small" vm.

Back when we were using Azure heavily, the answer from the Azure team members I was talking to was that they had no mechanism to warn me when the machine was going to go down.

The primary workload we were running was video game servers. The server stores all state ephemerally in RAM tied to the process. When it goes down, that play session is over and all players are booted. This was just a constraint of the software that we had to live with.

What I was looking for was some kind of heads up so that I could at least try and take down the process gracefully, but that wasn't possible.

As said, this was a while ago. Hopefully the situation is now different.

I'm not sure what you are saying is completely correct. However in the cloud you should design for that, everything will eventually fail and your service should manage. ie. avoid stateful VMs, provide sufficient redundancy etc. Design for failure. This is not just about Azure, it's a common cloud design practice.

Yes, you absolutely _should_ design for that. That's why it's kind of hard to get mad at this shortcoming, because the answer is just that you should have been following best practices anyway.

In practice, though, I often found myself getting annoyed that I had that enforced on me. On AWS or most other providers I've used, if you have a workload that isn't particularly mission critical you can get away with just expecting the machine to always stay up. It'll probably only go down once a year or so. Obviously not the best way to design a system, but a handy tradeoff to be able to make in order to save a little cash or complexity.

Well, the world does not move on ideal conditions. I have used AWS and Azure extensively. My use case has been mainly around hadoop ecosystem. Here is what happens on azure(HDInsights Specifically):

You have a cluster running, that does some work at certain times in a day. Out of the blue, Several machine would be "re-imaged" and that means it would delete all the logs, working directories etc.Its like a snapshot restore. So when this happens, you have lost any custom changes you had done on the cluster. You lose any 3rd party jars you had placed.

Those machines, join back your cluster and your jobs would no longer run because of missing jars Unless you program to download all files on every reboot.

Most important thing though is lack of prior notifications. I have had cases when a "re-image" happend when my CPU was 100% utilised and my RAM was used 90%. So my box was working on something and azure decided to apply a patch!!

As per frequency, its once every two weeks, sometimes more.

I don't really understand what the difference is between Linux running on a Linux host and Linux running on a Windows host. You're going to require updates and patches for both.

I haven't noticed any serious downtime on Azure for this reason. Probably 1 reboot in the last few months, with plenty of notice (and a fairly specific timespan).

Do you know that (have experienced, been told by a trustworthy source) or do you just assume?

So far, I had no issues regarding downtime at Azure at all. All downtimes were as stated in their policy.

It's monthly, however even that isn't really acceptable. So far I've been too lazy to figure out if one can setup the live migration stuff to act as workaround for this...not sure. It's definitely something they should at least address / give an official workaround for, or preferably just transparently handle it.

It used to be weekly, but yeah I've heard they've reduced the frequency of it these days.

I've had the same server up for months. Some of my workers roles on the other hand drop a bit.

Really ? http://technet.microsoft.com/en-us/library/hh831435.aspx

Virtual PC supports live migration. Seems like an easy way to do maintenance on the hosts. Does azure use live migration ?

I don't think Azure has a live migration. In fact, out of Google Cloud Platform, AWS and Azure only GCP has live migration of the running VMs.

It's worth noting that regardless of the fact that the underlying platform supports live migration, providing it as a service is requires an additional effort.

If users will favour GCE because of reduced downtime support due to the live migration support (or simply favour GCE because of they perceive it as a more advanced platform), then other providers will follow.

Right now it seems that it's all a price war, not yet a feature war. But prices can go down only to a point, then feature war will start showing it's effects, and it will be interesting.