Riverbed offers several of its products in virtual form factors. Virtual products are easily deployed and make more efficient use of compute resources. If your enterprise has a virtualization environment, these products can help you manage and accelerate application performance across the platform and your network.

Our virtual products are software that run on virtual machines. Virtual machines run on hypervisors, which in turn run on physical hardware. Before using a virtual product from Riverbed, ensure that you understand its requirements and that your virtualization environment can supply the necessary resources. Our virtual products are compatible with many virtualization platforms, and their requirements and setup can differ depending on the environment where you’ll be using them. To ensure successful deployment and operation, take time to understand the requirements, limitations, and best practices for the product and its target virtualization platform.

For information about technical specifications, go to the product family specification sheet.

These guidelines help you prepare your virtual environment for appliance deployment. Following them can help you avoid problems with your appliances and keep them running at optimal performance.

Use at least a gigabit link for each LAN/WAN interface. For best performance, ensure each LAN/WAN interface is backed by a dedicated NIC. Do not share physical NICs with other virtual machines. Using dedicated virtual switches and physical NICs also prevents network loops.

For all two-port NICs, ensure both ports are provided to the appliance. The number of NICs should always be even and in order; if they are not, the LAN/WAN pairs will not form properly and the appliance will not function properly.

Enable promiscuous mode for the LAN/WAN vSwitch. Promiscuous mode allows the LAN/WAN NICs to intercept traffic not destined for the appliance. Promiscuous mode is mandatory for traffic acceleration on in-path deployments.

For VMware, use distinct port groups for LAN and WAN virtual NICs connected to a vSwitch. If you are running multiple appliances on a single virtual host, you must add the LAN/WAN virtual NIC from each virtual machine into a different port group on each vSwitch. Using distinct port groups for each LAN or WAN virtual NIC prevents the formation of network loops.

When you provision the host virtual machine, account for overhead. Activity at the host, and even the hypervisor, level can produce some overhead, causing the virtual machine to exceed its configured reservations.

Set your BIOS power management settings to maximize performance, if available.

Always use server-grade physical CPUs, and avoid overprovisioning them. For example, if a physical host has a quad-core CPU, the host’s virtual machines together should use no more than four vCPUs. We recommend you do not use hyperthreading. Hyperthreading can cause contention for the cores, resulting in significant loss of performance.

Always reserve RAM and ensure there is extra for overhead. The total amount of virtual RAM provisioned to all of the host’s virtual machines should not be greater than the host’s amount of physical RAM.

Back the appliance’s data store with high-quality physical storage devices. Physical storage must support a high number of input/output operations per second (IOPS). For best performance, avoid sharing physical storage across multiple virtual machines. Always allocate an unshared disk.

If you don’t allocate sufficient resources, the Virtual Machine Configuration alarm will be triggered and display a message relevant to the underprovisioned resource.

For example, you might receive the following alarm message:

Port requirements for SteelHead Mobile:

If you’re using application control, you must allow these processes:

Typically, SteelHead Mobile endpoint software connects to server-side appliances through a virtual private network (VPN). If that is the case for your network, ensure that the VPN tunnel is not optimized. If the tunnel uses TCP for transport, ensure that your endpoint policies include pass-through rules for the VPN port number. Depending on your deployment scenario, you might want that rule to be the first in the rule list. If the port uses UDP, no rule is required.

VPNs that use IPsec as the transport protocol don’t need a pass-through rule because IPsec is its own non-TCP/IP protocol and, by default, the SteelHeads don’t optimize it.

For a complete list of supported VPN software, go to Knowledge Base article S14999.

You can deploy virtual appliances in the same scenarios as physical ones, with the exception that fail-to-wire requires that the physical host has Riverbed NICs. For deployments where a Riverbed bypass NIC is not an option, we recommend that you do not deploy your appliance in-path. If you are not using a bypass card, you can still have a failover mechanism by employing either a virtual in-path or an out-of-path deployment. These deployments allow a router using Web Cache Communication Protocol (WCCP) or policy-based routing (PBR) to handle failover.

NIC promiscuous mode is required for in-path deployments.

In a virtual in-path deployment, the appliance is virtually in the path between clients and servers. Traffic moves in and out of the same WAN interface, and the LAN interface is not used. This deployment differs from a physical in-path deployment in that a packet redirection mechanism, such as WCCP or PBR, directs packets to appliances that are not in the physical path of the client or server. In this configuration, clients and servers continue to see client and server IP addresses.

On appliances with multiple WAN ports, you can deploy WCCP and PBR with the same multiple interface options available on physical appliances.

For a virtual in-path deployment, attach only the WAN virtual NIC to the physical NIC, and configure the router using WCCP or PBR to forward traffic to the appliance for acceleration. You must also enable in-path out-of-path (OOP) deployment on the appliance. To do that, enable L4/PBR/WCCP/Interceptor Support on the General Service Settings page of Management Console.

In an out-of-path (OOP) deployment, SteelHead is not in the direct path between the client and the server. Servers see the IP address of the server-side SteelHead installation rather than the client IP address, which might have an impact on security policies. For a virtual OOP deployment, connect the primary interface to the physical in-path NIC and configure the router to forward traffic to this NIC. You must also enable OOP on the appliance. Also, these caveats apply to server-side OOP appliances:

SteelHead is software that delivers acceleration similar to that offered by the SteelHead hardware, while also providing the flexibility of virtualization. Built on the same underlying operating system as the physical SteelHead, SteelHead supports:

SteelHead does not support:

The product runs on VMware ESXi, Microsoft Hyper‑V, and Linux KVM hypervisors installed on industry-standard hardware servers. SteelHead on VMware vSphere is certified for the Cisco Service-Ready Engine (SRE) module with Cisco Services-Ready Engine Virtualization (Cisco SRE-V).

SteelHead supports up to 24 virtual CPUs and 10 interfaces.

SteelHead Central Controller (SCC) and SteelHead Mobile Controller provide central management and reporting for multiple, separate deployments of acceleration products. You can run multiple virtual instances of these controller products on a single physical host, provided that the host has sufficient resources. The amount of resources the host virtual machine needs depends on the number of appliances you plan to manage through the controller.

You can access controllers through HTTP, HTTPS, or SSH. Access is configured through the controller’s Management Console.

Use the following table to determine the resources needed for SCC. Use the 64-bit SCC when managing more than 100 appliances.

For SteelHead management, each controller instance requires port 80 and port 443 inbound from the SteelHeads and port 22 outbound from each controller instance to managed appliances.

The table below lists the recommended resources for the indicated number of managed endpoints. By default, the controller is configured to support 100 endpoints.

The controller uses disk 1 for management and disk 2 for statistics.

You need to have valid licenses installed on all managed appliances and endpoints. A missing base license on an appliance or endpoint can cause the health of the controller to become critical and temporarily invalidates other licenses on the controller.

The flexible data store feature supports a smaller data store size, down to a minimum 12 GB.

To change the disk size or add disks, you’ll need to power off the host virtual machine, and then detach the data store disk and attach a new, smaller one. Simply attempting to reduce the size of the existing disk will not work.

If you provide a disk size larger than the configured data store for the model, the entire disk is partitioned, but only the allotted amount for the model is used.

SteelHead models VCX70 through VCX110 support multiple data stores using Fault Tolerant Storage (FTS). We recommend that all data stores on an appliance be the same size.

Each appliance instance requires a primary and auxiliary interface. If you add additional interface pairs to the virtual machine, they are added as in-path acceleration interfaces. Total bandwidth and connection limits still apply, regardless of the number of interfaces.

The in-path limit is four LAN/WAN interface pairs, including bypass cards. If you want to use the bypass feature, you are limited to the number of hardware bypass pairs your model supports. The bypass feature is available on all supported virtualization platforms.

Riverbed NICs are available in two-port and four-port configurations. Third-party NICs without a bypass feature are supported for functionality other than fail-to-wire and fail-to-block, providing the underlying hypervisor supports them.

SteelHead models VCX30 through VCX110 support two bypass LAN/WAN interface pairs. These configurations have been tested: