Azure Cloud Service (Extended Support) VIP Swap后无法就地更新，提示Public IP已被占用

你遇到的这个问题确实挺闹心的，我之前处理扩展支持云服务的VIP Swap时也碰到过类似的后台状态不同步情况，给你梳理几个可行的解决方向和临时 workaround：

一、先排查并同步后台IP关联状态 #

大概率是Swap操作后，Azure后台的IP资源关联状态没及时更新，导致系统误判IP还被原服务占用。你可以用Azure CLI来验证并强制同步：

1. 先获取目标云服务（比如cs1）和对应公网IP（ip2）的资源ID：

   # 获取cs1的资源ID
   az cloudservice show --name cs1 --resource-group MyServiceResourceGroupName --query id
   # 获取ip2的资源ID
   az network public-ip show --name ip2 --resource-group MyServiceResourceGroupName --query id
   

2. 强制将ip2重新关联到cs1：

   az cloudservice update --name cs1 --resource-group MyServiceResourceGroupName --set properties.networkConfiguration.frontendIPConfigurations[0].publicIpAddress.id=<刚才获取的ip2资源ID>
   

执行完这个操作后，回到门户再尝试更新服务，看看报错是否消失。

二、修正配置文件的ReservedIP引用格式 #

扩展支持云服务和经典版在配置文件的IP引用格式上有细微差异，你提到门户导出的配置带Group MyServiceResourceGroupName ip2这种经典格式，但扩展支持更推荐用ARM资源ID的方式引用。你可以尝试修改配置文件为：

<ReservedIPs>
  <ReservedIP id="/subscriptions/你的订阅ID/resourceGroups/MyServiceResourceGroupName/providers/Microsoft.Network/publicIPAddresses/ip2"/>
</ReservedIPs>
</AddressAssignments>
</NetworkConfiguration>
</ServiceConfiguration>

替换掉其中的你的订阅ID、资源组名称和IP名称后，再尝试上传更新。

三、临时应急Workaround：用新IP完成更新再切回 #

如果上面的方法都不生效，可以试试这个应急方案：

1. 新建一个临时的Reserved Public IP
2. 修改cs1的配置文件，将ReservedIP指向这个新IP
3. 完成服务更新操作
4. 待更新成功后，再做一次VIP Swap（如果需要切回原来的ip2），或者直接保留新IP使用

验证是否为Azure后台Bug #

如果想确认是不是平台Bug，可以用CLI查看ip2当前实际关联的资源：

az network public-ip show --name ip2 --resource-group MyServiceResourceGroupName --query "ipConfiguration.id"

如果返回的结果是cs2的资源ID（而不是当前应该关联的cs1），那肯定是后台同步异常，这种情况建议直接提交Azure支持工单，让工程师帮忙修复关联状态。

备注：内容来源于stack exchange，提问作者Vasily Romanov