KVM deployment details and considerations
Guidance for KVM vSensors and Brains including CPU/RAM/Storage, capture ports, modifications required after deployment, use of SANs, vMotion, and unsupported hypervisors.
Applicability
This guidance supplements the general requirements for KVM Brains and vSensors/Stream. The majority of the guidance provided is for KVM vSensors, but the details around SANs and additional deployment considerations apply to KVM Brains as well.
Supported Virtual Machine Management Platforms
There are many virtual machine managers that use KVM as the hypervisor. Support is provided on a tiered basis as follows:
Recommended
Vectra runs quality assurance testing on these virtual machine managers and provides specific instructions and support for deploying virtual appliances.
Proxmox
Libvirt
Only Ubuntu and Red Hat are officially supported as hosts.
Likely Functional
Vectra has not validated these virtual machine managers, but they meet the basic requirements for running a Vectra KVM virtual appliance.
Any virtual machine manager that has the following virtual hardware support is likely functional:
QEMU based (recommended QEMU version 4.0 or newer, minimum 2.12)
Recommended host Linux kernel version 5.0 or newer (minimum 4.9)
Legacy BIOS boot
High-performance VirtIO network interfaces and disks
Any KVM virtual machine manager that does not meet these requirements will not be able to run a Vectra virtual appliance.
Examples of likely functional virtual machine managers:
OpenStack
oVirt
Oracle Cloud Infrastructure
Examples of virtual machine managers that do not meet these requirements and therefore will not be able to run a Vectra virtual appliance:
Firecracker (not QEMU based, doesn't support BIOS boot)
kvmtool (not QEMU based)
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
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 4 vCore models require at least 8 GB, the 8 vCore model requires at least 16 GB, and the 16 vCore model requires at least 64 GB. 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.
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 below for more details.
Capture Ports
Each capture port can capture traffic from all VLANs on one vSwitch.
All KVM vSensors support one virtual capture port
16 Core vSensor Required Modifications
The 16 core vSensor will need its configuration modified after deployment due to limitations in what can be preconfigured when using one image file for multiple different deployment configurations.
16 core requires 500 GB storage.
Brain 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 critical that Brains do not have their CPU and RAM usage restricted. Restricting Brain resources in this manner will negatively affect both metadata processing and system stability.
RAM
The 8 vCore models require at least 64 GB, the 16 vCore model requires at least 128 GB, and the 32 vCore model requires at least 256 GB. Lower RAM allocations are not supported and will affect both system performance and system stability.
Storage
All Brain sizes require 128GB for the first disk and 512GB for the second.
Vectra recommends that Brains are configured to use storage local to the hypervisor and are not stored on a SAN. Vectra Brains require very 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 below for more details.
Networking Requirements
General KVM Networking Requirements
KVM based virtual appliances do not support DirectPath or SR-IOV passthrough.
KVM based virtual appliances do not support emulated network adapters.
KVM based virtual appliances do support paravirtualized NIC.
Vectra uses the virtio-net driver for all ports.
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
Live Migration / Moving / Copying
Live Migration is similar to vMotion if you are familiar with VMware terminology.
Vectra recommends that any automatic movement of the VM from one physical host to another be disabled for vSensors/Stream but it can be used with KVM Brains.
For KVM 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). 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 KVM Brains only:
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 KVM Brain will need to be relicensed when it is rebooted because it will have a new UUID.
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.
Last updated
Was this helpful?