# Service Chaining 1.0 deployment ## Guidance for Using the Nutanix Prism Central REST API In many of the following deployment steps we will be showing example Prism Central REST API v3 calls. Additional guidance for using the API can be found at the following links: * [GET /api/nutanix/understanding-rest-api](https://next.nutanix.com/how-it-works-22/get-api-nutanix-understanding-rest-api-38358) * [Nutanix API versions – What are they and what does each one do?](https://www.nutanix.dev/2019/01/15/nutanix-api-versions-what-are-they-and-what-does-each-one-do/) * [Accessing the REST API Explorer](https://portal.nutanix.com/page/documents/details?targetId=Prism-Central-Guide-vpc_7_3:mul-rest-api-explorer-pc-t.html) Most customers find it easier to use dedicated API tools such as [Postman](https://www.postman.com/) or [Insomnia](https://insomnia.rest/) to make API calls. API calls can also be made using [curl](https://curl.se/) or built into code for programmatic execution. Vectra does not endorse any specific tool for making the calls. Vectra will provide the type of REST call (GET, POST, DELETE, etc), endpoint, and instructions or body examples in this guide for execution using the tool of your choice. Vectra provides a `.json` Postman collection that can be imported as an attachment below. {% file src="" %} This will need to be modified to add your Basic Auth credentials. Also the Prism Central Hostname or IP `{{pc_hostname_or_ip}}` variable will need to be configured with the IP or hostname of your Prism Central deployment. We will highlight important pieces of data that may also need to be used in subsequent calls and highlight where we used them. **Checking Task Status** Some of the calls required to complete the configuration will return a `status` section with a `state` of `PENDING` and a `task_uuid`. To check the status of these tasks a `GET` operation can be executed against the /tasks endpoint. Below is an example response showing this along with a task check and response. Abbreviated response example: ``` { "status": { "state": "PENDING", "execution_context": { "task_uuid": "3acead7a-bfec-4adb-b75c-733f191631ef" } } . . . ``` Task status check request: ``` GET - https://192.168.50.9:9440/api/nutanix/v3/tasks/3acead7a-bfec-4adb-b75c-733f191631ef ``` Response example: ``` { "status": "SUCCEEDED", "last_update_time": "2022-08-22T19:05:36Z", "logical_timestamp": 2, "entity_reference_list": [ { "kind": "network_function_chain", "uuid": "24936fa3-54e5-4ae2-a80c-411fae635236" } ], . . . ``` ## Service Chaining 1.0 Deployment Overview Before proceeding with the deployment, it is important to understand that certain parts of the deployment **MUST** happen in order. Some steps will have multiple options to complete the steps and alternative methods may be mentioned but not detailed. For example, images can be uploaded to your Nutanix environment using both Prism Element (PE) or Prism Central (PC), but PE and PC maintain separate image libraries. If the image was uploaded via PE, you must deploy the vSensor VM via PE. Significant differences for alternate methods will be called out. Below is an overview of the major steps: {% stepper %} {% step %} #### [Create vSensor VM](#id-1.-create-vsensor-vm-do-not-power-on-after-creation) * Add only the standard NIC that will be used for management (MGT1) at this time, the network function NIC will be added later. * If deploying via Prism Central, the disk size can be altered during deployment for 4, 8, or 16 core vSensors. {% hint style="warning" %} **Please Note:** DO **NOT** Power on the vSensor VM after creation because additional configuration changes must be made before booting the vSensor. {% endhint %} {% endstep %} {% step %} #### [Increase vSensor VM Disk Size (if required)](#id-2.-increase-vdisk-size-vsensor-vm-if-required) If deploying via PE, and you are deploying a 4, 8, or 16 core vSensor, you must increase the disk size of the vSensor using the ACLI. {% endstep %} {% step %} #### [Create Network Function Provider Category and Value](#id-3.-create-network-function-provider-category-and-value) Using the Prism Central UI, you will create the Network Function Provider category and value to be assigned to the Network Function Chain and VM in later steps. {% endstep %} {% step %} #### [Retrieve Cluster Name, UUID, and CVM IP](#id-4.-retrieve-cluster-name-uuid-and-cvm-ip) Using Prism Element, we need to retrieve cluster details – we’ll need the name, UUID, and CVM IP for configuring the Network Function Chain and accessing the ACLI. {% endstep %} {% step %} #### [Create Network Function Chain in AHV Cluster](#id-5.-create-network-function-chain-in-ahv-cluster) This step must be done using the Prism Central REST API. {% endstep %} {% step %} #### [Update the Still Powered Off VM](#id-6.-update-the-still-powered-off-vm) Using both the ACLI and PC GUI or PC API: * Update the powered off vSensor VM using ACLI on your CVM by performing the following: * Set the VM to be an agent and system VM. * Create the network function NIC (this will be the capture port of the vSensor) and set it to **TAP** type. * Set VM affinity to the specific AHV host you intend to use it on (this can also be done in PE GUI). * Get the UUID of the network function VM (the vSensor you are deploying). * Add the network function provider category and value to the vSensor VM using Prism Central UI. {% endstep %} {% step %} #### [Direct Traffic to the Network Function Chain](#id-7.-direct-traffic-to-the-network-function-chain) Repeat step 7 to add additional subnets as required. {% endstep %} {% endstepper %} {% hint style="info" %} **Please Note:** When deploying multiple vSensors or deploying in multiple AHV clusters, keep in mind the following: * A single network function chain is required for each AHV cluster in your Nutanix deployment. * A Vectra vSensor is required for each node of your AHV cluster when using Service Chaining 1.0. * The vSensor should be sized to handle the expected traffic volume from the subnets that will be observed on each respective node of the cluster. {% endhint %} ## 1. Create vSensor VM In this step you will create a vSensor VM using either [Prism Element](#prism-element-pe-vsensor-creation) (if you uploaded the vSensor images using PE) or [Prism Central](#prism-central-pc-vsensor-creation) (if you uploaded the vSensor using PC). {% hint style="warning" %} **Please Note:** DO **NOT** Power on the vSensor VM after creation because additional configuration changes must be made before booting the vSensor. {% endhint %} ### Prism Element (PE) vSensor Creation If your vSensor images were uploaded to PE, navigate in PE to *VM → + Create VM* and a scrolling dialog box similar to the below will open where you will need to fill out the required details for the VM. ![](https://content.gitbook.com/content/HJ1ltuWFvsArFWtevnRn/blobs/L09tR3fJK3I9ESJJ1jIS/Nutanix_vSensor_Deployment_Guide-2025_Nov_6-2.png) See guidance for each choice below along with an example of a fully configured dialog box: * **Name** – Use a name of your choice. * **Description** – Optional. * **Timezone** – Configure per your standards. * **Use this VM as an agent VM** – We will enable this at the ACLI later or you can enable this now. * **vCPU(s)** – 2, 4, 8, or 16 depending on the chosen configuration. * Look at [Nutanix vSensor Requirements and Performance](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/introduction-and-requirements#nutanix-vsensor-requirements-and-performance) for guidance. * **Number of Cores Per vCPU** – Always enter 1. * **Memory** – 8, 8, 16, or 64 GB depending on your chosen configuration. * **Boot Configuration** – Legacy BIOS and leave the **Set Boot Priority** at its default. * **Disks** * Delete the existing CD-ROM. * Add the QCOW2 image as a new disk. * **Type** – Disk. * **Operation** – Clone from Image Service. * **Bus Type** – SCSI. * **Image** – Select the QCOW2 image that you uploaded. * **Size** – This will be greyed out. If this needs to be modified based on your configuration, we will do this using the ACLI later. * **Index** – Next Available. * Add the `seed.iso` image as a new CD-ROM. * **Type** – CD-ROM. * **Operation** – Clone from Image Service. * **Bus Type** – IDE. * **Image** – Select the `seed.iso` image that you uploaded. * **Size** – This will be greyed out and does not need to be modified. * **Index** – Next Available. * **Volume Groups** – Ignore. * **Network Adapters** – Add a NIC on the network of your choosing where you want the management (MGT1) interface of the vSensor to attach. * **VM Host Affinity** – We will set this later at the ACLI or you can choose the node you wish to PIN to now. A vSensor should be installed on each node in the AHV cluster. * **Custom Script** – Ignore. * When done click the **Save** button but **DO NOT POWER ON YOUR VM**. ![](https://content.gitbook.com/content/HJ1ltuWFvsArFWtevnRn/blobs/CNcl8dd0OFtOwckMmeqr/Nutanix_vSensor_Deployment_Guide-2025_Nov_6-11.png) ### Prism Central (PC) vSensor Creation If your vSensor images were uploaded to Prism Central, navigate in PC to *Infrastructure > Compute > VMs > Create VM* and you will be presented with a four page dialog to create the vSensor VM: #### Configuration - Page 1 * **Name** – Use a name of your choice. * **Description** – Optional. * **Project/Cluster** – Set if required for your org. * **Number of VMs** * Normally 1 if deploying a single vSensor. * This can be set to more than 1 if you are deploying multiple identically configured vSensors. The additional vSensors would be named with -1, -2, etc after the configured name. * **VM Properties** * Refer to [Nutanix vSensor Requirements and Performance](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/introduction-and-requirements#nutanix-vsensor-requirements-and-performance) for vSensor specification. * **CPUs** – Set to 2, 4, 8, or 16 based on the size vSensor you are deploying. * **Cores** – Always set to 1. * **Memory** – Set to 8, 8, 16, or 64 based on the size of vSensor you are deploying. * **Advanced Settings** – Not required. #### Resources - Page 2 * **Disks** – Add the disks per the screenshots below, cloning them from the uploaded vSensor images. * Disk size can be changed per the vSensor specifications to avoid doing it in [Step 2](#id-2.-increase-vdisk-size-vsensor-vm-if-required) below. * **Network** – Attach to the subnet of your choice. * This will be where the Mangement (MGT1) interface of the vSensor will be connected. * Initially it will boot with DHCP, but this can be changed to static at the CLI of the vSensor. * See [Initial vSensor configuration at vSensor CLI](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/nutanix-vsensor/initial-vsensor-configuration-at-cli) for details. * **Boot Configuration** * This must be set to **Legacy BIOS Mode** with **Default Boot Order (CD-ROM, Disk, Network)**. * The `seed.iso` (CD-ROM) is read during vSensor boot to help configure network adapters. * **Shield VM Security Settings** – Not required. #### Management - Page 3 * **Enable ‘Default-Storage’ Policy** * Whether you enable this or not will depend on your defaults. * As per the [Nutanix vSensor Requirements and Throughput](#nutanix-vsensor-requirements-and-throughput): * Vectra recommends that Sensors are configured to use storage local to the hypervisor and are not stored on a SAN. Vectra vSensors require extremely high throughput from their disk storage and this throughput cannot normally be sustained by SAN systems without impact to other SAN users. * Also keep in mind that you will be pinning (setting affinity) for each vSensor to a specific node in each cluster. * **Categories** * If you don’t already have a category and value from prior vSensor deployments, leave this blank for now. * If you have already created the category and value in [3. Create network function provider category and value](#id-3.-create-network-function-provider-category-and-value) and are deploying a new vSensor in this cluster, you can set the network\_function\_provider category and value that you previously created and won’t have to do it later in [6. Update the still powered off VM](#id-6.-update-the-still-powered-off-vm). * **Timezone** – Configure per your standards. * **Use this VM as an Agent VM** * The vSensor needs to be set as an **Agent VM**. * This can be enabled now, or it can be set during [6. Update the still powered off VM](#id-6.-update-the-still-powered-off-vm). Some configuration must be done at the CVM ACLI later anyway. * **Guest Customization** – Not required. #### Review - Page 4 * Review the settings, go back and change anything if required, and when ready, click **Create VM**. #### Screenshot Examples Full Prism Central VM configuration example screenshots below. Click to enlarge any image.

Configuration - Page 1

Resources - Page 2

Addiing seed.iso as CD-ROM on Resources - Page 2

Adding .qcow2 as Disk on Resources - Page 2

Attach to Subnet on Resources - Page 2

Management - Page 3

Review - Page 4

## 2. Increase vDisk Size vSensor VM (if required) If you didn’t increase the disk size during the vSensor VM creation (only possible when creating via Prism Central), do it now. This is only required for VMs requiring a disk larger than the default of 100GB. Replace `` with the name of your Vectra Sensor VM. See [Nutanix vSensor Requirements and Performance](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/introduction-and-requirements#nutanix-vsensor-requirements-and-performance) for sizes. Login to one of your controller VMs (CVM), and enter the ACLI command line. You can use the CVM Virtual IP from Prism Element. To find this, click on your cluster name in Prism Element and copy the **Virtual IP**. ![](https://content.gitbook.com/content/HJ1ltuWFvsArFWtevnRn/blobs/almgQWN8GVJlAv2WjZmR/Nutanix_vSensor_Deployment_Guide-2025_Nov_6-23.png) ``` acli vm.list This will show you the list of VMs and allow you to easily see the VM name if you don’t have it handy. acli vm.get ``` Find the disk in the output and note the `device_uuid` as shown on the highlighted line below. The full output is much longer we are showing only the `disk_list` portion that is relevant: 
disk_list {
      addr {
        bus: "scsi"
        index: 0
      }
      container_id: 4
      container_uuid: "4adfaee8-5d13-43d0-9e2c-0acb78c20bf3"
      device_uuid: "85c6d790-7aec-4976-b8f7-a399b69f7597"
      naa_id: "naa.6506b8d2082195bbdbc2a81ffab4b6f0"
      vmdisk_size: 26843545600
      vmdisk_uuid: "5d5d00bb-3fa7-4a06-acb8-ba95f4efdab3"
    }
Use this `device_uuid` to expand the disk size to match the storage requirements. Syntax: ``` acli vm.disk_update device_uuid= new_size= ``` Example: ``` acli vm.disk_update device_uuid=85c6d790-7aec-4976-b8f7-a399b69f7597 new_size=150G ``` ## 3. Create Network Function Provider Category and Value All of the vSensor VMs need to be configured with a category called `network_function_provider` with a value of your choice. Vectra suggests using `vectra_vsensor` for the value, but this can be any value that you will consistently use moving forward. [vSensor Deployment Step 3 Alternate API Instructions](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/appendix-service-chaining-1.0-alternate-api-instructions#vsensor-deployment-step-3-alternate-api-instructions) can be used if you wish to do this via API. In this step, you will create the category and value. * A category with a key of `network_function_provider` will be created in Prism Central. * The values of this key will act as labels on the network function VMs that identify them on each host. * The key name of `network_function_provider` must **not** be changed. * Later, when the network function chain (NFC) is configured, it will also be tied to this category and value which means that the NFC will apply to any Vectra vSensor VM that has the same category and value. **Instructions:** * Navigate in your Prism Central (PC) UI to *Infrastructure → Administration → Categories* and click **New Category**. * **Name** – This **must** be set to `network_function_provider` and cannot be altered. * **Purpose** – Can be left blank or enter the text of your choice. * **Values** – Vectra suggests `vectra_vsensor` but this can be any value that you will use consistently. ![](https://content.gitbook.com/content/HJ1ltuWFvsArFWtevnRn/blobs/uGvwwKWv6rHWJoCPuEkr/Nutanix_vSensor_Deployment_Guide-2025_Nov_6-13.png) * When you type in a value, a new box appears. You do not need to do anything with this. Just **Save** when you are done. * After saving, search for your newly created category in the category list and validate it was created properly. ![](https://content.gitbook.com/content/HJ1ltuWFvsArFWtevnRn/blobs/2mInvj4qBzawMgNd9AXV/Nutanix_vSensor_Deployment_Guide-2025_Nov_6-12.png) ## 4. Retrieve Cluster Name, UUID, and CVM IP In this step you will retrieve the Cluster Name, UUID, and CVM IP where the Network Function Chain will be created. [vSensor Deployment Step 4 Alternate API Instructions](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/appendix-service-chaining-1.0-alternate-api-instructions#vsensor-deployment-step-4-alternate-api-instructions) can be used if you wish to do this via API. It is recommended to do this step via the UI instructions below as they are typically easier for customers. At this point it is useful to make sure that you are keeping track of data that you will need to recall in later parts of the overall deployment process. Please make sure that you are keeping track of the following: * From the cluster details page in Prism Element. Click on your cluster name in Prism Element ![](https://content.gitbook.com/content/HJ1ltuWFvsArFWtevnRn/blobs/FbeonOviFYymrKN8wO7n/Nutanix_vSensor_Deployment_Guide-2025_Nov_6-14.png) * **Network Function Provider** * The value you created in step 5. Vectra recommends `vectra_vsensor` . * **CVM Virtual IP** * Any CVM (there is one per node) in the cluster can be used, the virtual IP is usually easiest. * Some configuration steps must be done using the ACLI later. * **Cluster Name** – Will be required when creating the network function chain in the next step. * **Cluster UUID** - Will be required when creating the network function chain in the next step. * In Step 5.2 you will also collect: * **Network Function Chain UUID** – UUID for later use when assigning subnets to the NFC. * You want the UUID from the metadata portion of the response. ## 5. Create Network Function Chain in AHV Cluster This step requires Prism Central API calls. You will create a network function chain (NFC) in the AHV cluster using the network\_function\_provider value, cluster name, and UUID gathered in the previous steps. You will also provide a “name” value for the NFC. In our example below our network function chain will have a value of “vectra\_tap”. * Please note that if you are deploying in multiple AHV clusters, you will need to repeat network function chain setup for each cluster you are deploying Vectra vSensors in. ### 5.1 - Create the Network Function Chain In this step you will create the Network Function Chain with a name of your choice using the gathered values. ``` POST - https://{{pc_ip}}:9440/api/nutanix/v3/network_function_chains ``` Body: * Modify the body below with NFC name, category value, name and UUID of the cluster you are deploying in. Lines with entries are highlighted * Vectra suggests using `vectra_tap` for the Network Function Chain Name. * You will also need the `network_function_provider` category value we created earlier. Vectra suggests using `vectra_vsensor` . * Finally you will also need the name and UUID of the cluster you are deploying this NFC in. 
{
    "spec": {
        "name": "vectra_tap",
        "resources": {
            "network_function_list": [
                {
                    "network_function_type": "TAP", 
                    "category_filter": {
                        "type": "CATEGORIES_MATCH_ANY",
                        "params": {"network_function_provider": ["vectra_vsensor"]}
                    }
                }
            ]
        },
        "cluster_reference": {
            "kind": "cluster",
            "name": "nutanix2 ",
            "uuid": "0005dd45-7584-73d2-07af-52540083d046"
        }
    },
    "api_version": "3.1.0",
    "metadata": {
        "kind": "network_function_chain"
    }
}
Response example: 
{
    "status": {
        "state": "PENDING",
        "execution_context": {
            "task_uuid": "3acead7a-bfec-4adb-b75c-733f191631ef"
        }
    },
    "spec": {
        "name": "vectra_tap",
        "resources": {
            "network_function_list": [
                {
                    "network_function_type": "TAP",
                    "category_filter": {
                        "params": {
                            "network_function_provider": [
                                "vectra_vsensor"
                            ]
                        },
                        "type": "CATEGORIES_MATCH_ANY"
                    }
                }
            ]
        },
        "cluster_reference": {
            "kind": "cluster",
            "name": "nutanix2",
            "uuid": "000639fc-7386-2da4-7938-bc2411a17fee"
        }
    },
    "api_version": "3.1",
    "metadata": {
        "owner_reference": {
            "kind": "user",
            "uuid": "00000000-0000-0000-0000-000000000000",
            "name": "admin"
        },
        "use_categories_mapping": false,
        "kind": "network_function_chain",
        "spec_version": 0,
        "uuid": "24936fa3-54e5-4ae2-a80c-411fae635236"
    }
}
### 5.2: Verify that the network function chain is created * Using [earlier guidance](#guidance-for-using-the-nutanix-prism-central-rest-api), you can check the task UUID for completion if desired. * In this step, we will ask the API to list the network function chains to validate creation. * The UUID of the network function chain that is listed in the metadata portion of the response example below will need to be used [Step 7: Direct traffic to the configured network function chain](#direct-traffic-to-the-configured-network-function-chain). Please keep track of this. ``` POST - https://{{pc_ip}}:9440/api/nutanix/v3/network_function_chains/list ``` Body: ``` { "kind": "network_function_chain" } ``` Abbreviate Response Example: Note the highlighted lines showing the expected output. 
{
    "api_version": "3.1",
    "metadata": {
        "kind": "network_function_chain",
        "offset": 0,
        "length": 1,
        "total_matches": 1
    },
    "entities": [
        {
            "status": {
                "name": "vectra_tap",
                "resources": {
                    "network_function_list": [
                        {
                            "network_function_type": "TAP",
                            "category_filter": {
                                "type": "CATEGORIES_MATCH_ALL",
                                "params": {
                                    "network_function_provider": [
                                        "vectra_vsensor"
                                    ]
                                }
                            }
                        }
                    ]
                },
                "state": "COMPLETE",
                "execution_context": {
                    "task_uuid": [
                        "654f65d7-4e19-4222-8770-73b88129ba26"
                    ]
                }
            },
            "metadata": {
                "uuid": "9385b9d5-d2cf-4039-b3b1-45f5ef744e1a",
                "spec_hash": "00000000000000000000000000000000000000000000000000",
                "spec_version": 0,
                "owner_reference": {
                    "kind": "user",
                    "uuid": "71f50668-79f9-50d4-8dec-eaaf5a411f36",
                    "name": "admin"
                },
                "categories": {},
                "categories_mapping": {},
                "creation_time": "2025-09-15T20:25:10Z",
                "last_update_time": "2025-09-15T20:25:11Z",
                "kind": "network_function_chain"
            },
            "spec": {
                "cluster_reference": {
                    "kind": "cluster",
                    "name": "nutanix2",
                    "uuid": "000639fc-7386-2da4-7938-bc2411a17fee"
                },
                "name": "vectra_tap",
                "resources": {
                    "network_function_list": [
                        {
                            "category_filter": {
                                "params": {
                                    "network_function_provider": [
                                        "vectra_vsensor"
                                    ]
                                },
                                "type": "CATEGORIES_MATCH_ANY"
                            },
                            "network_function_type": "TAP"
                        }
                    ]
                }
            }
        }
    ]
}
## 6. Update the Still Powered Off VM In this step we'll use both the ACLI and Prism Central UI to update the still powered off vSensor VM. **6.1 Overview:** * Set the VM to be an agent and system VM. * Create the network function NIC and set it to TAP type. * Tie the vSensor VM to a specific node so that is not moved from this node and captures traffic on this node. * This is setting an affinity to a specific node (also known as pinning). * If you already did this during [Prism Element (PE) vSensor Creation](#prism-element-pe-vsensor-creation), you do not need to do this again. * If you created the VM using Prism Central, you must set the affinity using the ACLI or the Prism element UI. **6.2 Overview:** * Add the network function provider category and value to the still powered off vSensor. #### 6.1 - Update the Network Function VM (vSensor) * Log in to a CVM in your target cluster and access the ACLI. * Execute the below ACLI commands for each network function VM (vSensor). * One vSensor is needed for every node and assign affinity to each node. * You may have already set the vSensor as an agent VM during creation, if so, you don’t need to do it again, but there is no harm in just copying/modifying the entire command below and doing it again. * `vSensor_Name` should be replaced by your vSensor name and `x.x.x.x` should be the IP of the node you are setting affinity to. Affinity can also be set in the GUI without needing to find the IP of the node you are setting affinity to: * Navigate in your Prism Element UI (for the cluster you are working on) to the VM table view, select your vSensor VM and click the **Update** button. * Scroll down to the bottom and set the affinity to the specific node you desire. ![](https://content.gitbook.com/content/HJ1ltuWFvsArFWtevnRn/blobs/dcYN6EXLwa7Na36hRFmX/Nutanix_vSensor_Deployment_Guide-2025_Nov_6-15.png) ``` nutanix@CVM $ acli vm.update vSensor_Name agent_vm=true extra_flags=is_system_vm=true vm.nic_create vSensor_Name type=kNetworkFunctionNic network_function_nic_type=kTap vm.affinity_set vSensor_Name host_list=X.X.X.X ``` #### 6.2 - Add the Network Function Provider Category/Value to the vSensor [vSensor Deployment Step 6 Alternate API Instructions](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/appendix-service-chaining-1.0-alternate-api-instructions#vsensor-deployment-step-6-alternate-api-instructions) can be used if you wish to do this via API. It is recommended to do this step via the UI instructions below as they are typically easier for customers. * Navigate in your Prism Central UI to *Infrastructure → Compute → VMs*. * Right click on your vSensor VM and choose *Other Actions >→ Manage Categories.* * Search for `network_function` and find the `network_function_provider` category and value you created earlier. * The display can be scrolled inside the box to see the entire value for the category. * Save the setting in the bottom right. ![](https://content.gitbook.com/content/HJ1ltuWFvsArFWtevnRn/blobs/A4QmSKM3ntgQqaWIg0I3/Nutanix_vSensor_Deployment_Guide-2025_Nov_6-20.png) ## 7. Direct Traffic to the Network Function Chain Nutanix supports 3 ways to direct traffic to the network function chain: 1. Flow security policies to selectively direct specific traffic flows to the network function chain. * This requires Flow licenses and is not in scope for this guide. 2. Directing an entire AHV network to the network function chain. * This is the example we will cover below. * Directing an entire AHV network through the network function chain does require Prism Central but does NOT require Flow licenses or microsegmentation. * An AHV network is called a `subnet` in the Prism Central v3 API. * This is the most likely scenario we expect customers to encounter. It allows for all the virtual traffic on an AHV network on a single hypervisor to be copied to the vSensor to allow for inspection. * The steps outlined here in Step 7 should be repeated for each subnet you want to direct to the vSensor. * Nothing needs to change with the vSensor configuration when you add or remove subnets to the network function chain. The vSensor does not need to be rebooted or told to analyze different subnets. The vSensor simply produces metadata for any traffic that it receives from the network function chain. 3. Direct a single VM NIC to the network function chain. * This is not in scope for this guide. {% hint style="info" %} **Please Note:** For options not covered in this guide, please work with your Nutanix account team to get assistance if you are not already familiar with the configuration of Flow or directing a single VM NIC to the network function chain. As stated in [Nutanix Traffic Capture Options](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/nutanix-vsensor/nutanix-traffic-capture-options), only VLAN Basic subnets are supported, if you are using NCVLAN Subnets, please note that NCVLAN does not support network function chains. [Traffic Mirroring](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/nutanix-vsensor/traffic-mirroring-deployment) supports functioning in environments that use NCVLAN Subnets. {% endhint %} **Overview of Required Steps** [vSensor Deployment Step 7 Alternate API Instructions](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/appendix-service-chaining-1.0-alternate-api-instructions#vsensor-deployment-step-7-alternate-api-instructions) can be used if you wish to do this via API. It is recommended to do this step via the UI instructions below as they are typically easier for customers. **7.1 - List Subnets** * In this step you will list the subnets and choose which subnets you wish to be routed through the network function chain. **7.2 - Add Network Function Chain (NFC) Reference to Subnet** * In this step you will update the subnet to reference the NFC. **7.3 - Validate NFC is Referenced in Subnet Details** * In this step you will an API call to validate that the subnet now references the NFC. **7.4 - (Optional) – Remove NFC Reference From a Subnet** * This step is optional and provided for an easy way to clear an NFC reference from a subnet. NFCs cannot be deleted when a subnet still references them. In some environments, “extra” NFCs may exist from prior attempts to configure service chaining in Nutanix. ### 7.1 List Subnets Access the ACLI of a CVM in your cluster (see [6. Retrieve Cluster Name / UUID Where the Network Function Chain Will Be Created](#retrieve-cluster-name-uuid-where-the-network-function-chain-will-be-created) for how to find the CVM IP if you don’t still have it handy.) Use the `net.list` command to show the subnets in your cluster. ``` net.list Network name Network UUID Type Identifier Virtual Switch Subnet default-subnet f5d8c6bb-8ad9-42c5-b977-8bafbba10b81 kBridged 0 vs0 test 5a4a32d9-76f6-4b40-8eda-eb2fa46899bc kBridged 100 vs0 ``` In our example above, we have two subnets. You will need the Network UUIDs of the subnets that you want to be mapped to the NFC. ### 7.2 Add NFC Reference to Subnet Use the `net.update_network_function_chain` to update each desired subnet to reference the NFC. ``` net.update_network_function_chain net.update_network_function_chain f5d8c6bb-8ad9-42c5-b977-8bafbba10b81 472f2d96-472d-4e6e-94d1-1ea66f2be89d ``` In the above example, we are adding a reference for the NFC UUID beginning with `472f2d96` to the default subnet UUID we found in step 7.1. Repeat this step for each subnet you wish to map to the NFC. ### 7.3 Validating the Subnet References the NFC Use an empty body in your request and put the desired subnet you want details for in the request URL. ``` https://{{pc_ip}}:9440/api/nutanix/v3/subnets/f5d8c6bb-8ad9-42c5-b977-8bafbba10b81 ``` Response Example: 
{
    "api_version": "3.1",
    "metadata": {
        "last_update_time": "2025-09-24T15:04:50Z",
        "kind": "subnet",
        "uuid": "f5d8c6bb-8ad9-42c5-b977-8bafbba10b81",
        "spec_version": 8,
        "creation_time": "2025-09-10T20:39:29Z",
        "categories_mapping": {},
        "categories": {},
        "owner_reference": {
            "kind": "user",
            "uuid": "71f50668-79f9-50d4-8dec-eaaf5a411f36",
            "name": "tbilen"
        },
        "spec_hash": "00000000000000000000000000000000000000000000000000"
    },
    "spec": {
        "resources": {
            "subnet_type": "VLAN",
            "vswitch_name": "br0",
            "network_function_chain_reference": {
                "kind": "network_function_chain",
                "uuid": "472f2d96-472d-4e6e-94d1-1ea66f2be89d"
            },
            "vlan_id": 0,
            "virtual_switch_uuid": "7925c9f7-c20f-44a8-b4e3-e4067048a755"
        },
        "cluster_reference": {
            "kind": "cluster",
            "name": "nutanix2",
            "uuid": "000639fc-7386-2da4-7938-bc2411a17fee"
        },
        "name": "default-subnet"
    },
    "status": {
        "name": "default-subnet",
        "cluster_reference": {
            "kind": "cluster",
            "name": "nutanix2",
            "uuid": "000639fc-7386-2da4-7938-bc2411a17fee"
        },
        "resources": {
            "virtual_switch_uuid": "7925c9f7-c20f-44a8-b4e3-e4067048a755",
            "vswitch_name": "br0",
            "network_function_chain_reference": {
                "kind": "network_function_chain",
                "uuid": "472f2d96-472d-4e6e-94d1-1ea66f2be89d"
            },
            "vlan_id": 0,
            "subnet_type": "VLAN",
            "ip_usage_stats": {
                "num_macs": 8
            }
        },
        "state": "COMPLETE",
        "execution_context": {
            "task_uuid": [
                "757c3ee0-decc-4638-9491-ab4ac8c292a7"
            ]
        }
    }
}
As you can see in the above example, the network function chain reference appears in the response. ### 7.4 Optionally Removing NFC Reference or Deleting an NFC If you ever need to delete a NFC or remove an NFC reference from a subnet, you can use the commands in this section to remove the NFC reference from a subnet. NFCs cannot be deleted when a subnet still references them. In some environments, “extra” NFCs may exist from prior attempts to configure service chaining in Nutanix. * To remove NFC reference from a subnet use the `net.clear_network_function_chain` command from your CVM ACLI as shown below: ``` net.clear_network_function_chain ``` * You can use the API call detailed in [5. Create Network Function Chain in AHV Cluster](#id-5.-create-network-function-chain-in-ahv-cluster) to list the NFCs in your cluster. * You can use a `DELETE` call to the `/api/nutanix/v3/network_function_chains/` Prism Central API endpoint to delete a NFC. Replace `` with the UUID of the NFC you wish to delete. Body Example: ``` { "kind": "network_function_chain" } ```