# VMware deployment details and considerations ## Applicability This guidance supplements the general requirements for VMware Brains and vSensors. The majority of the guidance provided is for VMware vSensors, but the details around SANs, and addtional deployement considerations apply to VMware Brains as well. ## vSensor Resource Requirements ### CPU Generations Supported The virtual CPU must support a minimum SSE instruction level of 4.2 and must support the POPCNT (population count) instruction. The modern Intel AVX and AVX2 instruction specifications includes SSE 4.2 support. This requires the hypervisor host to run one of the following processors or later: * Intel Nehalem (2008) processors and newer * AMD Bulldozer (2011) processors and newer It is important to note the restriction below regarding Enhanced vMotion Compatibility, where SSE/AVX support may be excluded from a hypervisor CPU due to the cluster composition. Vectra vSensors may run their CPU at close to 100% when bandwidth usage is close to the specified limit of the vSensor. This is expected and normal behavior. It is critical that vSensors do not have their CPU and RAM usage restricted. Restricting vSensor resources in this manner will negatively affect both capture performance and vSensor stability. ### RAM The 2 and 4 vCore models require at least 8 GB, the 8 vCore model requires at least 16 GB, the 16 vCore model requires at least 64 GB, and the 32 vCore model requires 114 GB of RAM. Lower RAM allocations are not supported and will affect both system performance and system stability. ### Storage 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 and 32 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](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/vsensor-deployment-in-vmware#modifying-16-and-32-core-vsensors-after-deployment) by the administrator from 150GB to 600GB for the 16 vCore and 830GB for the 32 vCore. 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. Please see [Storage Area Networks](#storage-area-networks) below for more details. 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. ### Capture Ports 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. * 32-core, please check below the section: "Required configuration parameters in advanced VM options for ONLY the 32 core vSensor" ## 16 and 32 Core vSensor Required Modifications The 16 and 32 core vSensors will need their configuration modified after deployment due to limitations in what can be preconfigured when using one image file for multiple different deployment configurations. Please see: [Modifying 16 and 32 core vSensors after deployment](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/vsensor-deployment-in-vmware#modifying-16-and-32-core-vsensors-after-deployment) for instructions. * 16 core requires 600 GB storage. * 32 core requires 830 GB storage and added ethernet configuration. * 32 core may also need NUMA parameters adjusted in advanced VM configuration options. ## Networking Requirements #### General VMware Networking Requirements * 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. #### 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. #### 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 ## Storage Area Networks Vectra recommends the Brain or vSensor appliance storage is local to the hypervisor. vSensors 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 requirements 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 vSensor 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. ## Additional Deployment Considerations ### vMotion / Moving / Copying Vectra recommends that vMotion be disabled for vSensors but it can be used with VMware Brains. **For VMware 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. Affinity rules should be used to keep the vSensor local to the hypervisor it was deployed on. In situations where you are not fully deploying vSensors to have complete coverage of your virtual environment (i.e. a limited deployment PoV), customers have successfully used affinity rules to keep a vSensor with a workload (such as an AD Server) and were able to participate in vMotion. They also used anti-affinity rules to keep from having more than one vSensor on the same physical host. These cases should be the exception, rather than the rule, and are not recommended for production deployments. vSensors may be shut down safely by the administrator if their services are not required upon the hypervisor they are currently deployed. **For VMware Brains only:** vMotion should not change the UUID of VMware Brain VMs. If the Brain VM is migrated to another location or lands on different underlying hardware, the Brain VM may get a new UUID. In such a case the VMware Brain will need to be relicensed when it is rebooted because it will have a new UUID. Please see the following Broadcom (VMware) KBs: * [Migrating Virtual Machines with vSphere vMotion](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vcenter-and-host-management-8-0/migrating-virtual-machines-host-management/migration-with-vmotion-host-management.html?utm_source=chatgpt.com) * [Changing or keeping a UUID for a moved virtual machine](https://knowledge.broadcom.com/external/article/320246/changing-or-keeping-a-uuid-for-a-moved-v.html) ### 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 (which is 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 for VMware vSensors or Brains: * VMware Workstation * VMware Fusion * Xen ### Running with reduced CPU/RAM allowance The minimum requirements for vSensors and Brains are hard limits; running with less RAM or CPU than the minimum required may cause the appliance to become unstable or unresponsive. Appliances 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 appliance as this will significantly degrade the performance of the appliance and will affect packet processing or stability.