VMware Virtual Sensor (vSensor) Deployment Guide¶

Document version

Based on the Vectra AI deployment guide of October 8, 2025.

Introduction¶

This guide is intended to help customers or partners deploy vSensors in VMware environments and pair them to a Vectra Brain. It covers basic background information, connectivity requirements (firewall rules that may be needed in your environment), vCenter integration, deployment of the vSensor in VMware, and pairing.

vSensors behave much like physical Sensors. One advantage is that there is no cost to deploy a vSensor other than the infrastructure you provide and maintain. vSensors also allow you to capture and analyse traffic that only exists in the virtual environment. You can even use vSensors in place of physical Sensors to capture physical network traffic.

VMware vSensors can be used in both Respond UX and Quadrant UX deployments. For more detail on Respond UX vs Quadrant UX, see Vectra Analyst User Experiences (Respond vs Quadrant). One of the below guides should be the starting point for your overall Vectra deployment:

Vectra Respond UX Deployment Guide
Vectra Quadrant UX Deployment Guide

Either of the above guides covers basic firewall rules needed for the overall deployment and initial platform settings. Virtual Sensor (VMware, Hyper-V, KVM, AWS, Amazon, and GCP) configuration and pairing are covered in their respective guides. Physical appliance pairing is covered in the Vectra Physical Appliance Pairing Guide. See the Vectra Product Documentation Index on the Vectra support site for additional documentation, including deployment guides for CDR for M365 / IDR for Azure AD and CDR for AWS.

About VMware vSensor Images¶

The Brain makes a VMware OVA available for download and subsequent use for provisioning vSensors. Vectra appliances typically operate with updates enabled, ensuring the latest version is running. Deployed Sensors and vSensors also update regularly from the Brain - once a vSensor has been deployed, it updates itself as needed, staying current with its Brain.

As your Vectra Brain is updated, the OVA for VMware is also updated.
- If you deploy additional VMware vSensors in the future, always download a fresh copy of the OVA from an up-to-date Brain to ensure you are working with the latest code.
- vSensor images are retrieved from the Brain whether using the Respond UX or Quadrant UX.

VMware vSensor Resource Requirements and Performance¶

Sizing is driven by target throughput on the capture interfaces.

Resource	500 / 250 Mbps	1 / 0.5 Gbps	2 / 1 Gbps	5 / 2.5 Gbps	20 / 10 Gbps
Capture interfaces	2²	2²	4	4	4
CPU cores	2	4	8³	16³	32³
Memory	8 GB	8 GB	16 GB	64 GB	114 GB
Storage	100 GB	150 GB	150 GB	600 GB⁴	830 GB⁴

vSphere: 6.5 to 8 (5.x was supported through v6.14, 6.0 was supported through v6.19).
vSwitch type: VMware Virtual Standard Switch (VSS) or VMware Distributed Switch (VDS, a.k.a. dvSwitch).

Supported VMware hardware versions and platform notes¶

Supported VMware hardware versions

Vectra supports only versions 11 and 15 of VMware hardware. Do not update the hardware version ever (during deployments, upgrades, or in any other situation). This includes updating from v11 to v15. Redeployment is the only supported way to change hardware between supported versions. If you move to an unsupported hardware version, Vectra Support will direct you to redeploy any VMware vSensor running an unsupported version. Downgrades are unsupported.

VMware-based vSensors do not support DirectPath or SR-IOV passthrough.
VMware-based vSensors do not support emulated network adapters.
VMware-based vSensors do support paravirtualized NIC - Vectra uses the VMXNET3 driver for all ports.
The virtual CPU must support a minimum SSE instruction level of 4.2 and must support the POPCNT (population count) instruction. This requires the hypervisor host to run one of the following processors or later:
- Intel Nehalem (2008) and newer
- AMD Bulldozer (2011) and newer
Vectra recommends that Sensors use storage local to the hypervisor rather than a SAN. vSensors require extremely high throughput from their disk storage, which cannot normally be sustained by SAN systems without impacting other SAN users.
See the Vectra support article for additional guidance around Storage/SANs, networking requirements, vMotion, Enhanced vMotion compatibility, and unsupported hypervisors.

Connectivity Requirements¶

The Vectra Respond UX Deployment Guide or Vectra Quadrant UX Deployment Guide detail basic connectivity requirements for initial platform deployment. They also cover firewall/proxy SSL inspection, Internet access to and from the Brain, and guidance for air-gapped environments. For the full set of possible firewall rules, see Firewall Requirements for Vectra Appliances. VMware vSensor-specific requirements are listed below.

Source	Destination	Protocol/Port	Description
Admin hosts	vSensors	TCP/22 (SSH)	CLI access to vSensor
Brain	vSensors	TCP/22 (SSH)	Remote management and troubleshooting
vSensors	Brain	TCP/22 (SSH), TCP/443 (HTTPS)	Pairing, metadata transfer, and ongoing communication
Brain	vCenter	Configured TCP Port(s)	Physical Hosts view, vCenter Host ID input, vCenter host context, vCenter alerts

Notes

vSensors do not communicate with the Vectra Cloud.
All communication sessions with vSensors are initiated from the vSensor to the Brain.
Updates for vSensors are downloaded to the Vectra Brain, and the vSensor retrieves them from the Brain.
Command-line access can also be obtained via the console in your hypervisor.

About VMware vCenter Integration¶

vCenter integration from the Vectra Brain enables a number of features:

Virtual Infrastructure view.
vCenter host information artifacts help feed Vectra's automated Host ID.
Additional VMware context is available for analysts on VMware hosts.
vCenter alerts are possible as an additional notification type.

Virtual Infrastructure View¶

Enabling vCenter API query connectivity helps with VMware vSensor deployment planning by identifying the physical hosts, clusters, and data centres that currently have vSensor coverage and those that do not.

Enabling the vCenter connection also shows available resources on physical VMware hosts and exposes configuration errors that might be affecting packet capture. This view, at Network Stats > Virtual Infrastructure, helps the Vectra admin identify the exact requirements that need to be conveyed to VMware operational teams.

With this integration, the security team may not need to rely on the IT team to be notified of changes impacting them.

Once vCenter integration is configured, the Network Stats > Virtual Infrastructure Hosts page is enabled in the Vectra GUI.

The filter dropdown controls what is shown on the Virtual Infrastructure page:

A red exclamation point means a physical hypervisor is NOT covered - either no vSensor is installed on the hypervisor or the installed vSensor cannot be detected.
A yellow warning sign means there is a configuration issue with the installed vSensor.
A green checkmark means the vSensor is configured and functioning properly.

vCenter Host ID artifacts¶

Vectra's automated Host ID is a key benefit for analysts. The goal is to provide human-readable names associated with known hosts.

Host names result from known information about the host. Each observed name is an artifact. Artifacts are typically added to a host record over time as more host activity is seen and better associations are made. Artifacts may be removed from a host depending on observed behaviours.

Hosts are tracked internally in a name-agnostic manner. When assessing host naming in your deployment, note that host names are decided at the time of viewing the web page - displayed names will change over time to reflect the most human-readable name given the artifacts available at the time of display.

The hostname obtained via vCenter/vSphere integration through an active query of the vCenter API is a key artifact when available. It is considered a best practice to enable vCenter integration even if you will not deploy VMware vSensors.

For additional information, see Understanding Vectra NDR Host Naming on the Vectra support portal.

Additional Host context for analysts¶

When an analyst views a host running VMware tools and reporting back to vCenter/vSphere with Vectra vCenter integration enabled, additional context is available. On the left-hand side of the host's page in the Vectra UI, look for summary info including the VM name and operating system as reported by the vCenter API. The Host Details view has a more complete view.

Example Host Details fields:

VMWARE
Host Name:      Piper-desktop
UUID:           7d994ee6-562c-471f-b196-40ad89400760
Physical Host:  hyp-2-37.sc.tvec
Cluster:        TMELab
Data Center:    TMELab
vCenter:        vndemo-vc01.sc.tvec
OS:             microsoft windows 10 (64-bit)
Power State:    poweredOn
Nets:           IPS              MAC
                192.168.150.100  00:50:56:93:b0:89

vCenter alerts¶

Once vCenter integration is configured, additional alerts are available for changes in the environment that may merit security consideration. To enable them, navigate to Settings > Notifications > Alert Emails, select the pencil / Edit icon, scroll to the bottom of Alert Emails settings, and enable the Send vCenter alerts toggle. Example scenarios where an alert will be sent:

A new physical hypervisor where a vSensor may be needed has been added to the environment.
A vSensor has been moved or powered down.
A VM is moved from a host monitored by a vSensor to a host not monitored by a vSensor.

Enabling vCenter Integration¶

Prepare a vSphere account for Brain access¶

To connect the Brain to vSphere, a vSphere user account and password must be configured on the Brain. The user account must have at least global, read-only rights. The Brain will not attempt to write any data to your VMware environment.

To ensure the vSphere user/group the Brain will use has global, read-only access, use the following steps in the vSphere UI:

From the vSphere Administration page, select Access > Global Permissions.
Click the + to display the global permissions dialog.
At the bottom of the left pane, click Add.
Ensure the domain is set correctly, select the users or groups you intend to use in Vectra's configuration to connect to the vCenter API, and click OK.
In the Assign Role section, select Read-Only from the drop-down list.
Make sure Propagate to children is selected, and click OK.

Configure vCenter/vSphere integration¶

You will need the IP or hostname of your VMware vCenter/vSphere server. You can configure multiple integrations if you have more than one server to connect to. You will also need the port number, username, and password.

Navigate to Settings > External Connectors > vCenter and edit the vCenter settings. Any previously configured vCenters are shown here.

Click + Add vCenter to add an additional vCenter, fill in the blanks, and click Save.

vSensor Deployment in VMware¶

Requirements¶

IP address and subnet mask for the Management interface of the vSensor.
DNS server addresses.
Administrative access to your VMware vCenter/vSphere console or authorisation to deploy via API connection.
To configure the vSensor after initial deployment, you will need access to the vSensor CLI either via the hypervisor console or via SSH.
- The vSensor can be deployed with a static IP using the vSphere UI in vCenter. When deployed using the embedded host client in ESXi, only DHCP is available for initial deployment.
- You must know the IP assigned via DHCP to SSH to the CLI, otherwise use the hypervisor console.
VMware-specific information is required:
- vSphere hostname or IP, VM name for the vSensor, datacentre hostname or IP, vmhost to deploy on, datastore, management portgroup, capture portgroup, vSwitch, number of cores.
Optional VMware-specific information for vSphere API-based deployment from the Brain CLI:
- vSphere port, resource path, hostname to assign, username, password.
Only use supported VMware hardware versions (v11 or v15). See earlier guidance.
For production monitoring, keep the vSensor VM running 24x7, and ensure the hypervisor does not overcommit resources or otherwise misrepresent the resources provided to the vSensor.
vMotion should not be enabled for vSensors.

Downloading the latest vSensor VMware OVA image¶

The current vSensor OVA can be downloaded from the Brain by clicking the blue Download Virtual Image link at the top right of Data Sources > Network > Sensors and selecting the VMware vSensor (OVA) option. It can take up to 45 minutes for newly deployed Brains to have all images fully processed and available for download. If an image doesn't show as available yet, try again later.

Available image options:

KVM vSensor (QCOW2)
Nutanix AHV vSensor (QCOW2)
Hyper-V vSensor (VHDX)
VMware vSensor (OVA)

VMware vSwitch types and port group guidance¶

VMware has two types of virtual switches: VSS (VMware/vSphere Standard Switch) and VDS (VMware/vSphere Distributed Switch). VSS is available at any license level (even "free" ESXi); VDS is only available with the Enterprise Plus license level.

vSensors need port groups configured in promiscuous mode to analyse all desired traffic on the physical hypervisor (ESXi host) they are deployed on. VLANs can be used to limit what traffic is analysed. The following diagrams provide additional detail.

VSS (VMware/vSphere Standard Switch)¶

 Host 1                    Host 2
 ┌──────────────────┐     ┌──────────────────┐
 │ vm1  vm2   Vectra│     │ vm3  vm4   Vectra│
 │  │    │     │    │     │  │    │     │    │
 │ PG Prod  PG Capt │     │ PG Prod  PG Capt │
 │   │   │   │      │     │   │   │   │      │
 │      VSS         │     │      VSS         │
 │       │          │     │       │          │
 └──────pNIC────────┘     └──────pNIC────────┘

vSwitch - defined per physical host.
Port group - defined per VSS.
PG VSS Capture:
- Set promiscuous mode.
- VLAN Filter: 0 (untagged), 4095 (all), or specific VLAN ID.
Promiscuous mode - if set, all traffic on VSS matching the VLAN filter is sent to the port group.

VDS (VMware/vSphere Distributed Switch)¶

 Host 1                    Host 2
 ┌───────────────┐        ┌───────────────┐
 │ Guest Guest V │        │ Guest Guest V │
 │   │     │   │ │        │   │     │   │ │
 │          VDS (spans hosts)              │
 │    PG Prod    PG Capture                │

vSwitch - spans ≤ 350 physical hosts.
Port group - defined per VDS.
PG Capture VDS:
- Set promiscuous mode.
- VLAN Filter: 0 (untagged), 0-4094 (all), VLAN ranges, comma-separated.
Promiscuous mode - if set, all host traffic on VDS matching the VLAN filter is sent to the port group of that host.

Preparing port groups¶

Capture port groups
- VSS
  - Security - promiscuous mode must be set to Accept so the vSensor receives all packets.
  - Properties - it is a best practice to set the VLAN ID to All (4095) so no packets are filtered by VMware before reaching the vSensor.
- VDS
  - Security - promiscuous mode must be set to Accept to receive all packets.
  - VLAN - VLAN type must be VLAN trunking with the VLAN range set to 0-4094 as a best practice so no packets are filtered by VMware before reaching the vSensor. Limit VLANs if required.
  - Forged transmits and MAC address changes should be set to Accept.
- VLANs can be limited to exclude certain VLANs from analysis, e.g. VLANs dedicated to I/O traffic such as iSCSI or vMotion. This can reduce load on the vSensor and allow smaller vSensors to be deployed.
Management port groups
- These may already exist in the customer environment.
- Used by administrator workstations to log in to the Vectra Brain UI and CLI.

VMware physical hosts and vSensor coverage¶

When deploying vSensors with VSS, customers need a vSensor per physical hypervisor or standalone ESXi host because the VSS is unique to each physical host. With VDS, it is still required to deploy a vSensor per physical host. VDS allows a single distributed switch to be shared across physical hypervisors, but local traffic (per hypervisor) is not forwarded across the VDS by default, even when another host has a port group set to promiscuous mode. The recommendation is:

Create a port group for monitoring (e.g. "Monitor"). You only need to create one such port group and it will be available for the entire VDS.
Place one vSensor per physical host.
Place the capture interface from the vSensors into the "Monitor" port group.
Set promiscuous mode for "Monitor" to Accept and set the VLAN to 0-4094 to monitor all current and future port groups / VLANs that may be placed on any host in the VDS.
- Alternately, use specific VLANs (singles and/or ranges) if you only want a subset of the traffic, or to exclude certain VLANs (e.g. I/O VLANs such as iSCSI, FCoE, vMotion).
This sends any traffic over the local (within the same ESXi host) vSwitch instance, matching the specified VLANs, to the local Monitor port group instance, to be picked up by the local vSensor's capture interface. The traffic will not forward across the VDS.

VMware remote monitoring solutions (e.g. remote packet mirroring) should not be used to replicate traffic from one hypervisor to a vSensor running on another hypervisor.

It is best practice to think of vSensors as being tied to the physical host they are deployed on. They should generally not participate in vMotion or clustering/failover configurations. In limited-coverage scenarios (e.g. PoV), customers have successfully used affinity rules to keep a vSensor with a workload (AD Server) and participate in vMotion, and anti-affinity rules to prevent more than 1 vSensor on the same physical host. These cases should be the exception, not the rule, and are not suitable for production deployments. Work with your Vectra sales/deployment/support teams for additional guidance.

VMware networking interface guidance¶

Management interface (MGT1)
- Referred to in the vSphere UI as mgt1 when creating the VM from the OVF template.
- After VM creation, it is represented as Network adaptor 1 in VMware.
Dedicated capture ports
- Referred to in the vSphere UI as eth0 when creating the VM from the OVF template.
- After VM creation, represented as Network adaptor 2, etc. in VMware.

Deploying the OVA¶

There are two ways to deploy the OVA into your VMware environment:

Using your vCenter/vSphere client or embedded host client for standalone ESXi servers.
Using the provision vmware vsensor CLI command from the Brain.

Deploying using your vCenter/vSphere client or embedded host client for standalone ESXi servers¶

vCenter/vSphere versions and clients vary. The general process for deployment via your vCenter/vSphere client also differs slightly between VSS and VDS vSwitch types. You may need to make adjustments for your environment.

For example, the web UI for ESXi 6.5 does not have full feature support for some standard OVA features, including specifying deployment options within an OVA. Because of this, it is not possible to deploy vSensors on standalone ESXi 6.5 Update 1 using the web UI. In such cases, deploy using the vCenter app or vSphere client, or use the Vectra CLI command provision vmware vsensor. For more information, see Provision vSensor using VCLI.

The general process for using the vCenter application or vSphere client to deploy the OVF:

Log in and navigate to Hosts and Clusters.
Right-click the host where the vSensor will be deployed and select Deploy OVF Template.
Use only supported VMware hardware versions (see earlier guidance).
A pop-up walks you through configuring the virtual appliance:
- Browse to the OVA downloaded from the Vectra Brain.
- Give the vSensor VM a name (this appears in vSphere and in the Brain).
- Assign it to a datacentre, cluster, and folder appropriate for your environment.
- Select the datastore.
- Do not change the virtual disk format - it should be thick provisioned.
- The port groups used for MGT1 and for capture should already be configured per Preparing port groups.
- Assign Network Adaptor 1 (MGT1) to the management port group.
- Assign Network Adaptor 2 to the capture port group.
- Configure DHCP or static assignment for MGT1 (only available in the vSphere/vCenter UI).
  - If a static IPv6 address is assigned during deployment, IPv6 support is automatically enabled. See IPv6 Management Support for Vectra Appliances.
Additional NICs for capture can be added after deployment if required per the VMware vSensor Resource Requirements and Performance guidance.
Review the final details and do not enable Power on Upon Completion if you need to add configuration options for a 32-core VM and/or change the disk size for 16- and 32-core VMs. See Modifying 16 and 32 core vSensors after deployment.
If you deploy using the embedded host client on a standalone ESXi host, you may receive a warning about ignoring a disk - this can be safely ignored. DHCP is the only option for initial deployment when using the embedded host client for ESXi.

Deploying a vSensor using the Vectra CLI on your Brain¶

The CLI tool is an easy and convenient way to deploy on vCenter/vSphere and ESXi standalone servers:

Ensure the capture and management port groups are already created per Preparing port groups.
Ensure any firewall allows the Brain to connect to the vCenter server (if applicable) and the ESX/vSphere server on port 443 (or alternate port if configured).
Log in to VCLI on the Brain as the vectra user.
Run the provision vmware vsensor command using the appropriate options.
Once successfully deployed and powered on, the new vSensor should automatically pair to the Brain if Automatic Pairing is enabled under Data Sources > Sensors > Sensor Configuration > Sensor Pairing and Registration.

Options for the provision vmware vsensor command can be displayed at the Brain CLI:

vscli > provision vmware vsensor -h
Usage: provision vmware vsensor [OPTIONS]

Uses ovftool along with the supplied information to provision new virtual
 sensors to vCenter or a standalone ESXi hypervisor.

Options:
 -vs,  --vsphere TEXT         IP or hostname of vCenter/vSphere instance [required]
 -vm,  --vmname TEXT          Virtual machine name to assign to the vSensor [required]
 -ds,  --datastore TEXT       Name of the datastore to create the virtual machine on [required]
 -m,   -mp, --mgmt_pg TEXT    Management NIC's portgroup name [required]
 -cp,  --capture_pg TEXT      Capture NIC's portgroup name [required]
 -s,   -vsw, --vswitch TEXT   Name of the vSwitch that the capture portgroup is on [required]
 -dc,  --datacenter TEXT      Name of the data center where the vsensor will be created on (vCenter only)
 -vh,  --vmhost TEXT          Name of the physical host that the vSensor will be created on (vCenter only)
 -d,   --dhcp                 Select DHCP or static IP, Netmask, Gateway for vSensor management (only supported on vCenter)
 -mip, --mgmt_ip TEXT         Static Management IP address (only supported on vCenter)
 -mnm, --mgmt_netmask TEXT    Static Management IP netmask (only supported on vCenter)
 -mgw, --mgmt_gw TEXT         Static Management gateway IP address (only supported on vCenter)
 -n,   --dns TEXT             Comma separated list of DNS server IP addresses (only supported on vCenter)
 -c,   --cores [2|4|8|16]     Number of cores for vSensor to use (default 4)
 -p,   --port INTEGER         vSphere port (default is 443)
 -r,   -rp, --resource_path TEXT   Folder/resource path in which a host is located, e.g. "Folder Name/Cluster name" (vCenter only)
 -f,   -fp, --force_promiscuous    if provided, promiscuous mode will be enabled on capture portgroup automatically
 -hn,  --hostname TEXT        vSensor hostname to assign (only supported on vCenter)
 -u,   --username TEXT        vCenter/vSphere username (you will be prompted if not provided)
 -pw,  --password TEXT        vCenter/vSphere password (you will be prompted if not provided)
       --wait-for-ip          If selected, command returns only when the sensor successfully got an IP address
 -h,   --help                 Show this message and exit.

Command syntax:

provision vmware vsensor < -vs vsphere > < -vm vmname > < -ds datastore > < -m mgmt_pg > < -cp capture_pg > < -s vswitch > [ -dc datacenter ] [ -vh vmhost ] [ -d ] [ -mip mgmt_ip ] [ -mnm mgmt_netmask ] [ -mgw mgmt_gw ] [ -n dns ] [ -c cores( 2 | 4 | 8 | 16 ) ] [ -p port ] [ -r resource_path ] [ -f ] [ -hn hostname ] [ -u username ] [ -pw password ] [ --wait-for-ip ]

Example command:

provision vmware vsensor -vs "vsphere.local" -vm "vSensor-01" -ds "esxhost2 NVMe" -m "10x3 Management Network" -cp "Vectra Analyzer" -s vSwitch1 -dc "Oakland" -vh "Production 17" -mip 10.0.3.92 -mnm 255.255.255.0 -mgw 10.0.3.1 -n 10.0.6.10 -c 2

Notes

The Vectra provision command uses VMware's ovftool along with the supplied information to provision vSensors.
Not all arguments are required - if a username or password is not specified, you will be prompted. If the number of cores is not specified, the default of 4 is used.
For additional information and troubleshooting if this command fails, see the Provision vSensor using VCLI Vectra support portal article.

Special Note: Embryo state of vSensor before pairing and updating¶

Immediately after the initial deployment of a vSensor, it is in an embryo state. The vSensor needs to be paired to a Brain, then receive a software update from the Brain, and finally update to become fully functional. During the time before pairing and updating, not all vSensor commands are functional.

To log in to a vSensor, the username is vectra and the initial password is changethispassword. After the vSensor is paired and updated, the initial login to the updated vSensor will force a password change.

For example, the show traffic stats command does not exist on vSensors in embryo state. To determine if your vSensor is still in embryo state, use show version. If the version string is empty, then the vSensor is still in embryo state. After pairing, upgrading becomes True once the vSensor has successfully downloaded an update image from the Brain and begun updating. Example output for a vSensor in embryo state:

vscli > show version
Upgrading: False
Version:

While in embryo state, use only commands related to pairing:

set brain
- Ordinarily, this command is not necessary - the vSensor image downloaded from your Brain is already set to pair with the Brain by hostname or IP, depending on how Data Sources > Network > Sensors > Sensor Configuration > Sensor Pairing and Registration is configured. For example, the Brain's IP is embedded into the vSensor image so that it already knows where to pair when booted.
- For DNS Name to be an option, a hostname must be configured for your Brain in Data Sources > Network > Brain Setup > Brain. If no hostname is configured, Management IP Address is the only option available.
- It is recommended to configure a hostname and use it for pairing when possible - this typically makes failover easier to manage when Brain IPs may change in failover scenarios.
set registration-token
- Typically also not required for embryo vSensors, since the downloaded vSensor is already configured to pair with the Brain it was downloaded from.
- If you need to pair with a different Brain, set registration-token enables the vSensor to pair with a Brain that did not provide the initial vSensor image download.
- Sensor registration tokens are created on a Brain and are valid for 24 hours after creation. To generate one, navigate to Data Sources > Network > Sensors > Sensor Configuration > Sensor Pairing and Registration.

Modifying 16 and 32 core vSensors after deployment¶

Per VMware vSensor Resource Requirements and Performance, the 16- and 32-core vSensor configurations must be modified after deployment due to limitations in what can be preconfigured in the image.

Ideally these modifications are done before the Sensor is powered on for the first time. It is still possible to make the required modifications after initial power-on, but the overall process is simpler and requires less manipulation if done first. In any case, the Sensor must be shut down before making the changes, then powered on after saving.

Modify the disk size for the 16- or 32-core vSensor:

Shut down the vSensor if already powered on.
Edit the VMware settings (embedded ESXi client or vCenter/vSphere client) for the Sensor.
Change the disk size to:
- 600 GB for the 16-core vSensor.
- 830 GB for the 32-core vSensor.
Save the configuration and power on the vSensor.

32-core vSensor ethernet modification:

Only required for the 32-core vSensor.
Shut down the vSensor if already powered on.
Edit the VMware settings for the Sensor.
Go to VM Options > Advanced and edit the configuration parameters. Add two new parameters:
- If the link speed is 10 Gbps, the linkspeed parameter is not required but is a best practice.
- Default link speed is 10 Gbps for a capture NIC; modify as required. 20 Gbps is the max throughput for the Sensor, but link speed can be set to match the physical NIC associated with this interface if capturing physical traffic, or the aggregate bandwidth required if combining multiple sources.
- Example for the 1st capture port (Network Adapter 2; MGT is Network Adapter 1 / eth0):
  - Name/Key: ethernet1.pNicFeatures → Value: 4
  - Name/Key: ethernet1.linkspeed → Value: 40000 (40 Gbps, adjust as needed)
- Repeat both parameters for any additional capture NICs (max of 4 capture NICs) - use ethernet2 for the 2nd capture port, ethernet3 for the 3rd, etc.

32-core vSensor NUMA configuration:

Applies only to the 32-core vSensor

No changes are required for other vSensor sizes.

VMware provides guidance for Using NUMA Systems with ESXi; Virtual NUMA Controls documents the parameters. The numa.vcpu.maxPerVirtualNode parameter controls NUMA configuration for Vectra VMware VMs. Vectra cannot set this parameter at the .ova level, and on some 32-core VMware vSensors (depending on the underlying hardware platform) the parameter must be set by the customer after VM deployment, or errors will be seen during boot.

If the VM reboots frequently (every 3-4 minutes), and show system-health at the vSensor CLI shows a message about NUMA, this is the issue. To avoid it, check and set the parameter before powering on the VM.

numa.autosize.vcpu.maxPerVirtualNode is an advanced parameter in VMware vSphere/ESXi that controls how many vCPUs ESXi can automatically assign to a NUMA node when handling wide VMs. By default, ESXi sets and manages this internally based on host NUMA topology, VM sizing, and hypervisor defaults. The value should be set to 16 so that each NUMA node gets an equal number of vCPUs.

To check the parameter and set it if required:

Go to VM Options > Advanced and edit the configuration parameters. Find:
```
numa.autosize.vcpu.maxPerVirtualNode    16
```
If the setting is 16, close the parameters/VM options.
If the setting is not 16, change it to 16, save the configuration, and power on the vSensor.

Capturing Physical Network Traffic Using a vSensor¶

It may be desirable to mirror traffic from a physical switch to a Vectra vSensor. There are two ways to mirror traffic from a physical switch into a VMware ESXi hypervisor host for monitoring by a vSensor:

Dedicated link to ESXi host - utilises a dedicated physical NIC on the host chassis to carry tagged or untagged traffic from the mirror session on the switch to the vSensor on the host.
VLAN tag over an existing trunked link - utilises a VLAN trunked over a link to the host.

Method 1: Dedicated link to ESXi host¶

Utilising a dedicated link from the physical switch to the ESXi host may require the addition of a dedicated vSwitch due to VLAN tagging. The following procedure outlines the steps required to set up ESXi's network for this.

Step 1 - add a new virtual switch:

In the Networking menu, choose Add standard virtual switch.
Create the new vSwitch by choosing the appropriate physical NIC attached to the mirror output port as the Uplink.
Under Security settings, enable Promiscuous mode.

Example configuration:

vSwitch Name: vSwitch2 Capture
MTU: 1500
Uplink 1: vmnic1 - Up, 1000 mbps
Security:
  Promiscuous mode: Accept
  MAC address changes: Reject
  Forged transmits: Reject

Step 2 - create a port group for the capture interface:

On the Port groups tab, click Add port group.
Enter VLAN ID 4095 to monitor all VLANs being trunked (including native) over the physical link from the switch.
Select the virtual switch created in the previous step for Virtual switch.
Ensure the port group's security settings are inherited from the vSwitch.

Example configuration:

Name: vSwitch2 Capture PG
VLAN ID: 4095
Virtual switch: vSwitch2 Capture
Security:
  Promiscuous mode:    Inherit from vSwitch
  MAC address changes: Inherit from vSwitch
  Forged transmits:    Inherit from vSwitch

Step 3 - configure the vSensor's network adapter:

Edit the settings of the Vectra vSensor.
Select the newly created port group for the appropriate capture interface:

Virtual Hardware:
  CPU:               2
  Memory:            8192 MB
  Hard disk 1:       100 GB
  SCSI Controller 0: LSI Logic Parallel
  Network Adapter 1: Management_50
  Network Adapter 2: Capture Network
  Network Adapter 3: vSwitch2 Capture PG
  CD/DVD Drive 1:    Datastore ISO file
  Video Card:        Specify custom settings

Click Save.

Step 4 - verify the vSensor is receiving packets:

Log in to the vSensor's CLI.
Run show traffic stats several times to verify the interface is receiving traffic and the packets_received counter is increasing. This command only functions after the vSensor has been paired and updated from the Brain. See Special Note: Embryo state of vSensor before pairing and updating.

Example output:

vscli > show traffic stats
eth1:
    Interface Up: True,
    Packet Errors: 0,
    Packets Dropped: 0,
    Packets Missed: 0,
    Packets Received: 569094021
vscli > show traffic stats
eth1:
    Interface Up: True,
    Packet Errors: 0,
    Packets Dropped: 0,
    Packets Missed: 0,
    Packets Received: 599300775

Method 2: VLAN tag over an existing trunked link¶

When a dedicated physical link between the switch and the ESXi host is not desired or possible, a switch's mirroring session output can usually be configured to output on a VLAN. Configuration on the physical network varies by deployment and network vendor - work with your networking team and/or vendor to complete physical network configuration.

Step 1 - create the port group:

Create a port group for the vSensor's capture interface.
In ESXi's Networking menu, choose the Port groups tab.
Click Add port group.
Enter the VLAN ID that the switch will be mirroring traffic over (4000 in this example).
Choose the appropriate virtual switch with the physical link trunking the VLAN.
Ensure Promiscuous mode is enabled under Security.

Example configuration:

Name: vSwitch0 Capture 4000
VLAN ID: 4000
Virtual switch: vSwitch0
Security:
  Promiscuous mode:    Accept
  MAC address changes: Inherit from vSwitch
  Forged transmits:    Inherit from vSwitch

Step 2 - configure the vSensor:

Edit the settings of the vSensor.
Select the newly created port group for the appropriate capture interface.

Step 3 - verify the vSensor is receiving packets:

Log in to the vSensor's CLI.
Run show traffic stats several times to verify the interface is receiving traffic and the packets_received counter is increasing. This command only functions after the vSensor has been paired and updated from the Brain. See Special Note: Embryo state of vSensor before pairing and updating.

Initial vSensor Configuration at CLI¶

If you are not using DHCP or would like to set a static address, log in to the vSensor CLI to set a static interface assignment. DNS for vSensors must also be configured at the CLI.

vSensor login at the CLI is similar to logging in to physical Sensors. The primary difference is that there is no physical serial console, IPMI/iDRAC, or similar ports to log in to. Log in via your hypervisor console or using SSH to the management port if it was preconfigured with DHCP.

Connect to the vSensor CLI via the hypervisor console or ssh vectra@<IP or Hostname> if DHCP assigned an IP you know.
- If the vSensor has appeared in the Brain UI, you should be able to see its IP address at Data Sources > Network > Sensors.
- The initial password is changethispassword - you'll be asked to change it when logging in to a paired and updated vSensor. See Special Note: Embryo state of vSensor before pairing and updating.

Once logged in, view set interface command syntax:

set interface -h
Usage: set interface [OPTIONS] [mgt1] [dhcp|static] [IP] [SUBNET_MASK]
[GATEWAY_ADDRESS]

Sets mgt1 to either dhcp or static ip configuration

Options:
  -h, --help  Show this message and exit.

Setting the IP address statically:

In v8.5+, IPv6 is supported on the MGT1 interface. For full details, including dual-stack support, see IPv6 Management Support for Vectra Appliances on the Vectra support portal. Below is how to enable IPv6 support (off by default) and the syntax for IPv4 and IPv6.

Enable/disable IPv6 support:

# show ipv6 enabled
IPv6 is disabled

# set ipv6 enabled
Response: ok

# show ipv6 enabled
IPv6 is enabled

# set ipv6 disabled
Response: ok

IPv4 and IPv6 syntax examples:

IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z

Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway

IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]

Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1

Change back to DHCP (default):
```
set interface mgt1 dhcp
```

Configure DNS. Syntax (up to 3 nameservers supported):

set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]

Example:

set dns 10.50.10.101 10.50.10.102

Verify DNS configuration:

show dns

After setting an IP and DNS, use set password to change the password. Alternatively, change all paired-Sensor passwords in bulk in the Brain UI at Data Sources > Network > Sensors > Sensor Configuration > CLI Password (Sensors) to keep them in sync.
- You will be asked to change the password after initial login to paired and updated vSensors.

Example:

vscli > set interface mgt1 static 172.16.12.11 255.255.255.0 172.16.12.1
Interfaces updated successfully
vscli > set dns 10.50.10.101
DNS Set: success
vscli > show interface
mgt1:
    Running:
        Gateway: 172.16.12.1,
        Ip: 172.16.12.11,
        Link Speed: 10Gbps,
        Link State: up,
        Mac: 00:0c:29:89:ad:a6,
        Mode: static,
        Netmask: 255.255.255.0
vscli > show dns
Id|Server       |Description
1  10.50.10.101  Configured DNS nameserver

Pairing VMware vSensors¶

vSensors do not offer a web UI.
- The Vectra Platform (Brain) has the GUI for vSensor management at Data Sources > Network > Sensors.
- Some vSensor configuration can be done at the CLI as the vectra user.
VMware vSensor images are already associated with the Brain they were downloaded from and will appear in the Brain Data Sources > Network > Sensors page when booted for the first time.
vSensors are unique to the Brain the image was downloaded from and cannot normally be paired to other Brains in your environment.
- With a Sensor Registration Token, a deployed vSensor can be paired to a Brain other than the one the image was originally downloaded from. See Additional Pairing Guidance.
Per the Vectra Respond UX Deployment Guide or Vectra Quadrant UX Deployment Guide, Sensors (including vSensors) support pairing by IP or hostname.
- Pairing by hostname is preferred in failover scenarios. See the guides above.
Once the vSensor is powered on and its interface is configured, the vSensor announces itself to the Brain.
- This can take a couple of minutes - check firewall rules if there is an issue.
- If the vSensor appears in Data Sources > Network > Sensors, it has made a successful HTTPS connection to the Brain.
- If the vSensor does not appear, check that the vSensor has IP connectivity and that TCP port 443 (HTTPS) is permitted through the firewall.
- If the vSensor is unable to pair, complete its initial update, or forward metadata to the Brain, check that TCP port 22 (SSH) is permitted through the firewall.
If the announce is successful, the vSensor appears at Data Sources > Network > Sensors.
If Auto Pairing is enabled in Data Sources > Network > Sensors > Sensor Configuration > Sensor Pairing and Registration, the pairing process begins automatically.
- Enabling Auto Pairing is a best practice during rollout.
If Auto Pairing is not enabled, the vSensor must be manually paired by clicking the Pair icon. A dialog box starts the pairing process.
Initially the Pairing Status shows Pairing once the vSensor has successfully announced itself to the Brain. Once pairing completes, Pairing Status changes to Paired and Status should change to Forwarding once traffic is successfully being forwarded from the vSensor to the Brain.

Notes

vSensors, like physical Sensors, update themselves to stay current with their Brain.
After pairing, the vSensor updates by receiving an update from the Brain. This process is automatic and no input is required.
Certain vSensor CLI functions and traffic functions become available only after the vSensor has fully updated.
Depending on the specific version of the vSensor, you may see errors or warnings when running CLI functions during the update period.
The vSensor can be renamed or have its location labelled as desired by clicking the pencil icon on the right of the vSensor.

Additional Pairing Guidance¶

Pairing with new or changed Brains:

If you have a backup of your Brain and restore it to a new Brain with the same configuration (IP or hostname), previously paired Sensors (including vSensors) will connect to the new Brain automatically - the Sensor state is saved in the backup.
If the Brain IP has changed but otherwise remains the same, the vSensors may be updated to the new IP address using the set brain command.
Existing tunnels must terminate to re-establish connection to a new Brain. This can happen a few ways:
- Naturally, because the original Brain is no longer reachable due to a firewall change, hardware or software failure, etc.
- Unpairing the vSensor from the original Brain and then attempting communication to the original Brain.
- Using the set brain command at the CLI terminates an existing tunnel and attempts to start pairing with a new Brain.
If you have a Brain that will not be restored from backup but you wish to pair an existing vSensor to, this is possible via a Sensor Registration Token:
- Retrieve or generate a current Sensor Registration Token from Data Sources > Network > Sensors > Sensor Configuration > Sensor Pairing and Registration in the Brain GUI.
- Run set registration-token <token> at the Sensor CLI.
- Finally run set brain <IP or Hostname> at the Sensor CLI (depending on whether you have selected to pair via management IP or DNS name in Data Sources > Network > Sensors > Sensor Configuration > Sensor Pairing and Registration).

vSensors and pairing by hostname vs IP:

The vSensor image downloaded from the Brain uses, by default, the Brain's IP address for pairing.
To generate a VM image that points at a hostname, set Data Sources > Network > Sensors > Sensor Configuration > Sensor Pairing and Registration Pair using DNS name.
When this setting is changed, it does not affect any previously paired (either by IP or hostname) vSensors.

Traffic Validation¶

See the following Vectra support article for recommendations on network traffic that should be examined and excluded from analysis:

Vectra Platform Network Traffic Recommendations

For a quick spot-check that you are receiving traffic via the vSensor, check the GUI and/or CLI for statistics. If the vSensor is seeing more than 1 Mbps of traffic, this will show in the GUI under Network Stats > Ingested Traffic after a few minutes.

You can see traffic flow immediately at the Sensor CLI using show traffic stats.
- This command only functions after the vSensor has been paired and updated from the Brain. See Special Note: Embryo state of vSensor before pairing and updating.
Run the command a few times in a row to see increasing packet counts.

Example output:

vscli > show traffic stats
eth1:
    Interface Up: True,
    Packet Errors: 0,
    Packets Dropped: 0,
    Packets Missed: 0,
    Packets Received: 569094021
vscli > show traffic stats
eth1:
    Interface Up: True,
    Packet Errors: 0,
    Packets Dropped: 0,
    Packets Missed: 0,
    Packets Received: 599300775

After sending traffic to your Sensors, it is a best practice to validate that the traffic observed meets quality standards required for accurate detection and processing. Vectra's Enhanced Network Traffic Validation feature provides alarms and metrics for validating traffic quality. See the Vectra support article:

Enhanced Network Traffic Validation (CLI)

Worldwide Support Contact Information¶

Support portal: https://support.vectra.ai/
Email: support@vectra.ai (preferred contact method)

The first number represents NDR/Detect-only performance. The second number represents performance with NDR/Detect and Match and/or Suspect Protocol Activity detections enabled. ↩
2-core and 4-core vSensors can use up to 4 capture ports if the RAM is updated to at least 10 GB. ↩↩
2- and 4-core vSensors throttle CPU usage, while 8-, 16-, and 32-core versions do CPU pinning to maintain performance. ↩↩↩
The 16- and 32-core vSensors need their configuration modified after deployment due to limitations in what can be preconfigured in a single image used for multiple configurations. See Modifying 16 and 32 core vSensors after deployment. 16-core requires 600 GB storage; 32-core requires 830 GB storage and added ethernet configuration, and may need NUMA parameters adjusted in advanced VM configuration options. ↩↩