假设我有以下情况。我的一个 Azure 角色实例恰好是在运行在故障服务器内的 VM 上启动的,但 Azure 接线过程没有发现任何问题。我以某种方式推断出这个事实——例如,我看到一个“不可能的”调用堆栈——在任何正常条件下都不会在我的程序中发生。
所以我希望 Azure 将我的实例移动到另一个 VM 并检查和修复底层硬件。
除了联系支持人员外,我该怎么做?
假设我有以下情况。我的一个 Azure 角色实例恰好是在运行在故障服务器内的 VM 上启动的,但 Azure 接线过程没有发现任何问题。我以某种方式推断出这个事实——例如,我看到一个“不可能的”调用堆栈——在任何正常条件下都不会在我的程序中发生。
所以我希望 Azure 将我的实例移动到另一个 VM 并检查和修复底层硬件。
除了联系支持人员外,我该怎么做?
几点评论:
话虽如此,我非常同意布赖恩的评论,即坏硬件不太可能导致“不可能”的调用堆栈。我建议打开一个支持事件,这样您就可以找到实际的根本原因,而不仅仅是修复最明显的症状。
我不认为你可以移动虚拟机。但是您可以创建一个新的暂存部署,将其交换到生产环境中,然后销毁旧的部署。您实际上无法保证 VM 位于不同的物理机器上,但似乎很有可能。VM 越大,它们位于不同服务器上的可能性就越大。
也就是说,您的问题似乎不太可能是由于硬件故障而不是一些细微的错误。