need to change Azure Virtual network address(Mgmt)Subscription for MS Accelerator deployed with Terraform by MS team

Satish B 190 Reputation points

Hello Team,

recently MS team deployed MS accelerator with Terraform. they passed Values Like Virtual network Name & address using bootstrap script. They are not shared bootstrap script . we need to change Azure Virtual network address(Mgmt)Subscription.

they used Same Virtual Network address for self hosted agents for Github actions.

How to proceed further to achieve goal. Please suggest.

0 comments No comments
Sign in to comment

2 answers

  1. Vallepu Venkateswarlu 10,000 Reputation points • Microsoft External Staff • Moderator

    Hi Satish B,

    It sounds like you need to resize the management VNet that the MS Accelerator module deployed via Terraform,but you don’t have the original bootstrap script.

    You essentially have two paths:

    Option 1 : Use Terraform to Import your existing Azure infrastructure into Terraform.

    First Install (Windows)

    winget install aztfexport

    Mac: brew install aztfexport

    After installing aztfexport, create a folder and run the command below to import existing Azure infrastructure into Terraform,follow to install https://github.com/Azure/aztfexport

    Note: aztfexport requires the Terraform executable to be installed and available in the $PATH with version v0.12 or later.

    Specify the Azure Resource Group that contains the resources you want to start managing through Terraform.

    aztfy <Resource-Group_Name>

    These command will generate Terraform code automatically, after completing the process, you can change the Vnet values and redeploy again. Ref: Azure Terrafy (aztfy)
    Option 2: Terraform Import command

    terraform import "azurerm_virtual_network.vnet_auto" "/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxid/resourceGroups/d-210-rg-ado-si-p-to-6/providers/Microsoft.Network/virtualNetworks/d-210-vnet-ado-si-p-to-1"

    Ref: Importing Terraform State in Azure

    Please👁 210246-screenshot-2021-12-10-121802.png
    and “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.

    0 comments No comments
    Sign in to comment

  2. AI answer

    Changing the management virtual network address space and/or subscription after a Terraform-based accelerator deployment is essentially a network and infrastructure refactor. From the provided information, the supported options in Azure are:

    1. Resize or extend the existing virtual network address space If the issue is IP overlap or insufficient IPs, and the goal is to change or extend the address range of the existing management VNet (including what is used by self-hosted GitHub Actions agents):
      1. In the Azure portal, go to Virtual networks.
      2. Select the management VNet that was created by the accelerator.
      3. Under Settings, select Address space.
      4. Perform one of the following:
        • Modify an existing address range (for example, change 10.1.0.0/16 to 10.1.0.0/18) as long as all existing subnets remain fully contained in the new range.
        • Add a new address range (for example, add 10.2.0.0/16) that does not overlap with any existing ranges.
        • Remove an address range only if there are no subnets in that range; otherwise, subnets and their resources must be deleted or moved first.
      5. Select Save.
      For automation:
      • Use PowerShell Set-AzVirtualNetwork to update the VNet address space.
      • Or use Azure CLI az network vnet update --address-prefixes to set the new address ranges.
      If the VNet is peered (for example, to other VNets used by the accelerator or self-hosted agents), resizing is supported without downtime on the currently peered address space. After each address space change, sync the peering so the peers learn the new prefixes.
    2. Adjust subnets if needed If subnets must be changed to fit a new address space:
      • Subnet address ranges can be changed only if there are no resources in the subnet. Otherwise, resources must be moved to another subnet or deleted.
      • After subnets are adjusted, ensure any NSGs, route tables, NAT gateways, and delegations are still correctly associated.
    3. Consider peering and dependencies for self-hosted agents Since the same VNet/address space is used for self-hosted GitHub Actions agents:
      • Ensure any new or modified address ranges do not overlap with other VNets used by those agents.
      • After resizing the VNet address space, sync all VNet peerings so that connectivity between management components and agents is preserved.
    4. Terraform and subscription move considerations The context provided covers how to change VNet address spaces and subnets, including in peered scenarios, but does not include a supported procedure for moving the existing VNet and its resources to a different subscription via Terraform. For a subscription move, typical approaches are:
      • Recreate the infrastructure in the target subscription with Terraform using updated variables (VNet name, address space, etc.), then migrate workloads.
      • Or use Azure’s resource move capabilities for VNets and dependent resources, then update Terraform state accordingly.
      However, these steps are not detailed in the provided context, so only the supported VNet address space and subnet changes described above can be relied on directly.

    In practice, to achieve the goal with the available supported operations:

    1. Update the management VNet address space (add/modify ranges) so it no longer conflicts and provides the required IP plan.
    2. Adjust subnets if necessary, ensuring no active resources remain in subnets whose ranges are being changed.
    3. Sync any VNet peerings after each address space change.
    4. Reconfigure self-hosted GitHub Actions agents if their subnet or IP addressing changes.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer