vSensor Requirements Summary
VMWare ESX (vCenter/vSphere)
2 vCores / 8 GB RAM / 100 GB disk / 2 Capture Ports* / 400 Mbps Monitoring
4 vCores / 8 GB RAM / 150 GB disk / 2 Capture Ports* / 1 Gbps Monitoring
8 vCores / 16 GB RAM / 150 GB disk / 4 Capture Ports / 2 Gbps Monitoring
16 vCores / 64GB RAM / 600 GB disk** / 4 Capture Ports / 5 Gbps Monitoring
*See notes below about capture port configurations
**Disk will need to be manually increased to 600GB after deployment, see note below under 'Storage'.
Virtual Sensor (vSensor) CPU usage
Vectra vSensors may run their CPU at close to 100% when bandwidth usage is close to the specified limit of the sensor. This is expected and normal behavior.
It is critical that vSensors do not have their CPU and RAM usage restricted. Restricting sensor resources in this manner will negatively affect both sensor capture performance and sensor system stability.
vSensor Resource Requirements
vSensors can be configured with either 2, 4, 8 or 16 vCores yielding capture performance of 400MBps, 1GBps, 2Gbps and 5Gbps respectively.
The virtual CPU must support a minimum SSE instruction level of 4.2 and must support the POPCNT instruction. This requires the hypervisor host to be running one of the following processors or later:
- Intel Silvermont processors
- Intel Goldmont processors
- Intel Nehalem processors and newer
- Intel Haswell processors and newer
- AMD Bulldozer-based processors and newer
- AMD Jaguar-based processors and newer
- AMD Piledriver-based processors and newer
The 2 and 4 vCore models require at least 8GB of RAM, while the 8 vCore model requires at least 16GB of RAM. Lower RAM allocations are not supported and will affect both system performance and system stability.
The 2 vCore model requires at least 100 GB of available storage, while the 4 and 8 vCore models require 150GB of available storage space.
The 16 vCore model will deploy with 150GB of storage due to limitations of the VMware OVA deployment methodology. This vSensor will need to have its storage manually increased by the administrator from 150GB to 600GB.
Vectra recommends that sensors are configured to use storage local to the hypervisor. If you are considering deploying your vSensor on remote storage please read the note below regarding running vSensors on Storage Area Networks.
Each capture port can capture traffic from all VLANs on one vSwitch.
- vSensors with 8GB of RAM support two virtual capture ports, this includes 2-core and 4-core vSensors in the default CPU/RAM configuration.
- vSensors with a minimum of 10GB of RAM support four virtual capture ports, this includes the 8-core vSensor in the default CPU/RAM configuration.
- 2-core and 4-core vSensors support up to four virtual capture ports if the VM settings are adjusted to have a minimum of 10GB of RAM.
VMware networking requirements
vSwitch (vNetwork Standard Switch or VSS) Portgroup requirements
- The promiscuous mode must be set to "Accept" within the port group's configuration settings (Edit Settings -> Security -> Promiscuous Mode).
- Within the vSensor VM settings, the VLAN ID (port group, vSwitch, or adapter) must be set to All (4095) to ensure no packets are filtered by VMware before reaching the virtual Sensor. See the step by step guide below for explicit instructions.
dvSwitch (vNetwork Distributed Switch or VDS) Portgroup requirements
- The promiscuous mode must be set to accept to ensure that the virtual Sensor is able to receive packets.
- VLAN type must be set to VLAN trunking with the VLAN trunk range set to 0-4094 to ensure that no packets are filtered by VMware before reaching the virtual Sensor
Vectra recommends that vMotion be disabled for vSensors.
vSensors should be considered 'local' to the hypervisor they are deployed on and should be configured to cover all relevant VMs on that hypervisor. vSensors should be deployed proactively for each hypervisor and remain on that hypervisor even if other VMs on that hypervisor are moved to other hypervisors.
vSensors may be shut down safely by the administrator if their services are not required upon the hypervisor they are currently deployed.
Enhanced vMotion Compatibility
Vectra has become aware that certain VMware cluster configurations will reduce the available CPU feature flags due to Enhanced vMotion Compatibility. With this feature enabled the cluster will inhibit CPU features on all CPUs so that all hypervisors in the clusters present the same CPU feature flags.
In these configurations, it is possible for the hypervisor to disable SSE4.2 support for the vSensor (required to operate normally) even when the underlying hypervisor CPU supports it.
Further information on EVC including strategies for enabling EVC for vSensors or disabling vMotion/EVC for the vSensor are available through your normal VMware support channel.
Unsupported hypervisors/virtual environments
The following hypervisors are not currently supported by vSensors:
- VMware Workstation
- VMware Fusion
- Nutanix, except where the vSensor can be deployed using standard VMware toolsets
The following network adapters are not currently supported by vSensors:
- DirectPath, SR-IOV Passthrough, or emulated network adapters
Running with reduced CPU/RAM allowance
The minimum requirements for vSensors are hard limits; running with less RAM or CPU than the minimum required may cause the vSensor to become unstable or unresponsive.
The vSensors will use almost all of the CPUs and require all RAM to be permanently available. The hypervisor should not be permitted to limit the CPU and RAM to the vSensor as this will significantly degrade the performance of the sensor and will affect packet processing or stability.
Storage Area Networks
Vectra recommends the vSensor storage is local to the hypervisor.
Virtual sensors will write the full incoming packet stream to disk as a rolling buffer for packet capture retrieval by the brain. The bandwidth of these writes is often a problem for network storage and may negatively affect the performance of the vSensor or other systems using the SAN.
Special consideration should be given to SAN replication systems, where vSensor disk images are replicated between SAN nodes. Due to the high disk throughput for vSensors replicating these disk images may be extremely expensive for SAN replication systems.
Should deployment to SAN be necessary by hypervisor architecture the SAN should be scaled to accommodate the full incoming packet capture stream at minimal latency.
For example A sensor capturing 2Gbps may write up to 250Mbytes/second to the storage subsystem on a continuous basis.
If the deployment requires network-attached storage particular attention should be paid to:
- Minimizing the network infrastructure between the hypervisor and the SAN.
- Ensuring that the SAN is capable of both reading and writing this data on a continuous basis.
- Provisioning the full storage space for the vSensor, do not deploy Sparse disks.
- Disk deduplication is likely to be ineffective due to the unique data written to disk by each vSensor.
(Please see the attached PDF "VECTRA vSensor Deployment - Step by Step")