使用Ansible为Azure provision虚拟机时名称生成非预期十六进制后缀

• 该问题和Azure侧的命名规则无关，核心是拼接VM、NIC名称时的Jinja模板逻辑错误。你用了{{ '%01x' | format(item) }}表达式拼接后缀，而%x格式符的作用是将传入的整数转换为小写十六进制字符串输出，并非直接输出十进制数字。
• 十进制101转十六进制恰好是65，和你实际生成的第一个VM后缀完全匹配；如果遍历的item值为201，转十六进制就是c9，也对应你提到的异常后缀格式，这就是命名不符合预期的直接原因。
• 额外存在两处配置隐患：一是NIC名称引用了未定义的变量resource_agg_string（你的变量清单里只有resource_odd_string），二是YAML缩进层级混乱，loop、任务级tags的缩进和模块块不对齐，容易引发Ansible解析错误。

• 移除错误的十六进制格式化逻辑：直接将原来的{{ '%01x' | format(item) }}替换为{{ item }}，即可直接输出loop遍历的十进制数字作为后缀，匹配你期望的vm-stage-sql-mine-101、vm-stage-sql-mine-102命名格式。
• 修正NIC名称的变量引用错误：把不存在的resource_agg_string替换为已定义的resource_odd_string，避免变量未定义的运行报错。
• 统一YAML缩进层级：确保loop、任务级tags和azure_rm_virtualmachine模块声明保持同级缩进，避免块结构混乱。

- name: 部署Azure环境SQL节点虚拟机
  azure_rm_virtualmachine:
    resource_group: "{{ resource_group_name }}"
    location: "{{ resource_group_location }}"
    name: "vm-{{ env }}-sql-{{ resource_odd_string }}-{{ item }}"
    vm_size: "{{ resource_odd_vmsizetype }}"
    network_interfaces: "nic-{{ env }}-sql-{{ resource_odd_string }}-{{ item }}"
    image:
      offer: UbuntuServer
      publisher: Canonical
      sku: '18.04-LTS'
    data_disks:
      - lun: "{{ resource_odd_data_disk_lun }}"
        disk_size_gb: "{{ resource_odd_data_disk_size }}"
    tags:
      env: "vm-{{ env }}-sql-{{ resource_odd_string }}"
  loop: "{{ range(resource_odd_countstart|int, resource_odd_countend|int + 1, 1)|list }}"
  tags:
    - sql_odd

内容的提问来源于stack exchange，提问作者Techiescorner