CODEWITHSUNDEEP
azurehardwareazure-web-rolesazure-worker-rolesdiagnostics
sharptooth
sharptooth

Reputation: 170549

How do I cause Azure move my instance if I decide the VM is faulty?

Suppose I have the following situation. One of my Azure role instances happens to be started on a VM that runs inside a faulty server but Azure wiring processes don't see any problems. I somehow deduce this fact - for example I see an "impossible" call stack - one that can't happen in my program under any normal conditions.

So I'd like Azure to move my instance to another VM and have the underlying hardware checked and repaired.

How can I do that except contacting support?

Upvotes: 0

Views: 156

Answers (2)

kwill
kwill

Reputation: 11008

A few comments:

  1. You can have this done, sortof, by calling support. The support team won't move your VM to a new server just because you ask, but they will work with you to determine if the physical server really is bad, and if so move it to out of service.
  2. RequestRecycle will only shut down the host process (ie. WaIISHost) and related processes and then restart them. It won't reboot the VM, clean boot, or redeploy.
  3. You can try a 'Reimage' from the portal or Powershell if you suspect you might have a corrupt Windows installation. A Reimage will recreate the Windows partition from scratch.
  4. In order to force a new VM to be on a new server you would have to do an in-place upgrade and modify the size of the VM (ie. go from Small to Medium). This will cause new VMs to be created on new servers. You can then do another in-place upgrade to revert back to the original size.

That being said, I strongly agree with Brian's comment that it is very unlikely that bad hardware is causing an 'impossible' callstack. I would recommend opening a support incident so you can find the actual root cause instead of just fixing the most visible symptom.

Upvotes: 3

Brian Reischl
Brian Reischl

Reputation: 7356

I don't think you can move a VM. But you could create a new staging deployment, swap it into production, and then destroy the old one. You can't actually guarantee that the VMs are on different physical machines, but it seems reasonably likely. The larger the VMs are, the more likely that they're on separate servers.

That said, it seems really unlikely that your problems are due to a hardware fault rather than some subtle bug.

Upvotes: 2

Related Questions