KVM is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (such as Intel VT). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, such as kvm-intel.ko.

You can run multiple virtual machines running unmodified OS images using KVM. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, and so forth.

Performance Tiers for Threat Defense Virtual Smart Licensing

The threat defense virtual supports performance-tiered licensing that provides different throughput levels and VPN connection limits based on deployment requirements.

See the "Licensing the System" chapter in the Secure Firewall Management Center for guidelines when licensing your threat defense virtual device.

See the Cisco Secure Firewall Threat Defense Compatibility Guide for the most current information about hypervisor support for the threat defense virtual.

The specific hardware used for the threat defense virtual deployments can vary, depending on the number of instances deployed and usage requirements. Each instance of the threat defense virtual requires a minimum resource allocation—amount of memory, number of CPUs, and disk space—on the server.

• Requires two management interfaces and two data interfaces to boot.

  Note	The threat defense virtual default configuration puts the management interface, diagnostic interface, and inside interface on the same subnet.

  • Supports virtIO drivers.

  • Supports ixgbe-vf drivers for SR-IOV.

  • Supports a total of 11 interfaces.

• The default configuration for the threat defense virtual assumes that you put both the management (management and diagnostic) and inside interfaces on the same subnet, and the management address uses the inside address as its gateway to the Internet (going through the outside interface).

• The threat defense virtual must be powered up on firstboot with at least four interfaces. Your system will not deploy without four interfaces

• The threat defense virtual supports a total of 11 interfaces—1 management interface, 1 diagnostic interface, and a maximum of 9 network interfaces for data traffic. The interface-to-network assignments must be ordered as follows:

  • Management interface (1) (required)

    Note

    You can optionally configure a data interface for the management center management instead of the Management interface. The Management interface is a pre-requisite for data interface management, so you still need to configure it in your initial setup. Note that the management center access from a data interface is not supported in High Availability deployments. For more information about configuring a data interface for the management center access, see the configure network management-data-interface command in the FTD command reference.

  • Diagnostic interface (2) (required)

  • Outside interface (3) (required)

  • Inside interface (4) (required)

  • Data interfaces (5-11) (optional)

See the following concordance of Network Adapter, Source Networks and Destination Networks for the threat defense virtual interfaces:

• Cloning a virtual machine is not supported.

• For console access, supports terminal server via telnet.

• For creating vNICs with IPv6 support configuration on KVM, you must create an XML file for each interface that consists of IPv6 configuration parameters. You can install vNICs with the IPV6 network protocol configurations by running these XML files using the command virsh net-create <<interface configuration XML file name>>.

  For each interface, you can create the following XML file:

  • Management interface - mgmt-vnic.xml

  • Diagnostic interface - diag-vnic.xml

  • Inside interface - inside-vnic.xml

  • Outside interface - outside-vnic.xml

  Example:

  To create an XML file for Management interface with IPv6 configuration.

  <network>
               <name>mgmt-vnic</name>
               <bridge name='mgmt-vnic' stp='on' delay='0' />
               <ip family='ipv6' address='2001:db8::a111:b220:0:abcd' prefix='96'/>
          </network>
  

  Similarly, you must create XML file for other interfaces.
  You can verify the virtual network adapters installed on KVM by running the following command.

  virsh net-list
           brctl show
  

CPU Mode

KVM can emulate a number different of CPU types. For your VM, you typically should select a processor type which closely matches the CPU of the host system, as it means that the host CPU features (also called CPU flags) will be available in your VMs. You should set the CPU type to host in which case the VM will have exactly the same CPU flags as your host system.

Clustering

Clustering is supported on threat defense virtual instances deployed on KVM. See Clustering for Threat Defense Virtual in a Private Cloud for more information.

Performance Optimizations

To achieve the best performance out of the threat defense virtual, you can make adjustments to the both the VM and the host. See Virtualization Tuning and Optimization on KVM for more information.

Receive Side Scaling—The threat defense virtual supports Receive Side Scaling (RSS), which is a technology utilized by network adapters to distribute network receive traffic to multiple processor cores. Supported on Version 7.0 and later. See Multiple RX Queues for Receive Side Scaling (RSS) for more information.

Support for SR-IOV

SR-IOV Virtual Functions require specific system resources. A server that supports SR-IOV is required in addition to an SR-IOV capable PCIe adapter.

Threat Defense Virtual on KVM using the SR-IOV interfaces supports mixing interface types. You can use SR-IOV or VMXNET3 for the management interface and SR-IOV for the data interface.

You must be aware of the following hardware considerations:

• The capabilities of SR-IOV NICs, including the number of VFs available, differ across vendors and devices. The following NICs are supported:

  • Intel Ethernet Server Adapter X710

  • Intel Ethernet Server Adapter X520 - DA2

  • Intel Ethernet Network Adapter E810-CQDA2

    • The firmware (NVM image) and network driver is updated on Intel® Network Adapter E810 using an NVM utility tool. The Non-Volatile Memory (NVM) image and network driver are a compatible set of components that you update as a combination on the Intel® Network Adapter E810. For information on NVM and Software compatibility matrix, refer to the Intel® Ethernet Controller E810 Datasheet to update the correct firmware drivers on Intel® Network Adapter E810.

• Not all PCIe slots support SR-IOV.

• SR-IOV-capable PCIe slots may have different capabilities.

• x86_64 multicore CPU — Intel Sandy Bridge or later (Recommended).

  Note	We tested the threat defense virtual on Intel's Broadwell CPU (E5-2699-v4) at 2.3GHz.

• Cores

  • Minimum of 8 physical cores per CPU socket.

  • The 8 cores must be on a single socket.

    Note	CPU pinning is recommended to achieve full throughput.

• You should consult your manufacturer's documentation for SR-IOV support on your system. For KVM, you can verify CPU compatibility for SR-IOV support. Note that for the threat defense virtual on KVM we only support x86 hardware.

Limitations of using ixgbe-vf Interfaces

Be aware of the following limitations when using ixgbe-vf interfaces:

• The guest VM is not allowed to set the VF to promiscuous mode. Because of this, transparent mode is not supported when using ixgbe-vf.

• The guest VM is not allowed to set the MAC address on the VF. Because of this, the MAC address is not transferred during HA like it is done on other threat defense virtual platforms and with other interface types. HA failover works by transferring the IP address from active to standby.

  Note	This limitation is applicable to the i40e-vf interfaces too.

• The Cisco UCS-B server does not support the ixgbe-vf vNIC.

• In a failover setup, when a paired threat defense virtual (primary unit) fails, the standby threat defense virtual unit takes over as the primary unit role and its interface IP address is updated with a new MAC address of the standby threat defense virtual unit. Thereafter, the threat defense virtual sends a gratuitous Address Resolution Protocol (ARP) update to announce the change in MAC address of the interface IP address to other devices on the same network. However, due to incompatibility with these types of interfaces, the gratuitous ARP update is not sent to the global IP address that is defined in the NAT or PAT statements for translating the interface IP address to global IP addresses.

Snort

• If you are observing abnormal behavior such as Snort taking a long time to shut down, or the VM being slow in general or when a certain process is executed, collect logs from the threat defense virtual and the VM host. Collection of overall CPU usage, memory, I/O usage, and read/write speed logs will help troubleshoot the issues.

• High CPU and I/O usage is observed when Snort is shutting down. If a number of threat defense virtual instances have been created on a single host with insufficient memory and no dedicated CPU, Snort will take a long time to shut down which will result in the creation of Snort cores.

You have two options to manage your Secure Firewall Threat Defense Virtual.

• Download the threat defense virtual qcow2 file from Cisco.com and put it on your Linux host:

  https://software.cisco.com/download/navigator.html

  Note	A Cisco.com login and Cisco service contract are required.

• For the purpose of the sample deployment in this document, we are assuming you are using Ubuntu 18.04 LTS. Install the following packages on top of the Ubuntu 18.04 LTS host:

  • qemu-kvm

  • libvirt-bin

  • bridge-utils

  • virt-manager

  • virtinst

  • virsh tools

  • genisoimage

• Performance is affected by the host and its configuration. You can maximize the throughput of the threat defense virtual on KVM by tuning your host. For generic host-tuning concepts, see Network Function Virtualization: Quality of Service in Broadband Remote Access Servers with Linux and Intel Architecture.

• Useful optimizations for Ubuntu 18.04 LTS include the following:

  • macvtap—High performance Linux bridge; you can use macvtap instead of a Linux bridge. You must configure specific settings to use macvtap instead of the Linux bridge.

  • Transparent Huge Pages—Increases memory page size and is on by default in Ubuntu 18.04.

  • Hyperthread disabled—Reduces two vCPUs to one single core.

  • txqueuelength—Increases the default txqueuelength to 4000 packets and reduces drop rate.

  • pinning—Pins qemu and vhost processes to specific CPU cores; under certain conditions, pinning is a significant boost to performance.

• For information on optimizing a RHEL-based distribution, see Red Hat Enterprise Linux6 Virtualization Tuning and Optimization Guide.

• For KVM and System compatibility, see Cisco Secure Firewall Threat Defense Compatibility Guide.

• You can use the following methods to verify whether your virtual machine is running the KVM:

  • Run the lsmod to list the modules in the Linux Kernel. If the KVM is running, it is indicated by displaying the following output:

    root@kvm-host:~$ lsmod | grep kvm


    kvm_intel 123675 0


    kvm 257361 1 kvm_intel

• If ls -l /dev/kvm does not exist on the target VM then you are probably running qemu, and not taking advantage of the KVM hardware assist features.

  root@kvm-host:~$ ls -l /dev/kvm

  crw------- 1 root root 10, 232 Mar 23 13:53 /dev/kvm

• Run the following command to also check whether the host machine supports KVM:

  root@kvm-host:~$ sudo kvm-ok

• You can also use KVM acceleration.