Installing Virtual Riverbed Steelhead Appliances

Im currently creating a lab for internal testing purposes and proof of concepts for Riverbed WAN optimizations. A few years ago, I did install quite some Riverbed Steelhead Appliances (Hardware) and the installation (not configuration) was quite straight forward ( if you dont mess up the cabling :)). But its a bit different now with virtual Appliances, we got licenses (amongst others) for two virtual Steelhead Appliance for the lab. Installing the Appliance itself is not too hard (if you know vSphere and I dont, but I got a nice coleague which did give me a little Howto). Choose the .ova file from the Riverbed page and put it into the ESX/vSphere and start the Appliance, go to the console and use the startup wizard to configure the basic settings for the system. The virtual Appliance can now be accessed over the GUI.

What got me was the licensing and the assigned hardware for the appliance ( I dont like to read installation manuals ;)).
There are currently two different virtual Steelhead appliances:

Virtual Steelhead xx50 Models
Virtual Steelhead CX xx55 Models

The former line is now end of life and the CX xx55 models are now new available since about a month or two. Both lines do have only one installation file, the specifications of the different models within the line are activated over the corresponding license key. Crossupgrading between the two lines does not work.

The license I got is one for a VCX1555H, the virtuall appliance with the highest throughput and concurrent connections but the base installation is the one for a VCX555M (smallest appliance) and thats what the installation file does request from vSphere. To be able to use the virtual Appliance as a VCX1555H vSphere has to assign more CPUs, RAM and Disk Space for the Datastore. The corresponding values can be taken from the table below:

Riverbed vSHA Hardware Requirements

The license for a 1555H can be installed even if the appliance does not have enough hardware, but it cannot be activated.



  1. Renzo

    Hello pashtuk,

    I would like to know where did you get the maximun number of connections (concurrent TCP connections I think) that you show in the table and if there is a link on the riverbed web page where we can get that information (actually I was looking for that without success).

    Maybe I am wrong and the maximun number of concurrent TCP do not depend of the virtual appliance but the Operating System installed on the server. I will appreciate your comments.



    • pashtuk

      Hi Renzo
      sure, you can find the table in the Virtual Steelhead Appliance Installation Guide which is available on the Support Website from

      The Maximum TCP Connections is a limitation which is defined by the licence you have. Riverbed (on virtual Steelheads) limits the concurrent TCP connections artificially based on your licenses (= how much you pay). Same thing on hardware appliances, if you pay for a -L appliance, they will restrict the connections, since the appliance itself could handle the connections which are specified in the -H license.

      • Renzo

        Thank you for your quick response Pashtuk,

        Just one more thing I will appreciate if you can help me with your opinion. I have a requirement in order to install WAN optimizers which should support 500 and 40000 TCP concurrent connections on links of 1 and 6 Mbps, respectively.

        After I saw the Riverbed table, I start to think that this requirement is weird because the throughput vs supported TCP connections ratio is absolutely different for what Riverbed offers. I mean, Riverbed supports 6000 connections for throughputs of 100mbps, since the requirement asks to support 40 000 connections!!! for a throughput of only 6mbps.

        Do you think that there is something wrong with the requirement or this kind of ratio is possible and Riverbed or other branches have solutions for that?


      • pashtuk

        Hi Renzo
        welcome, happy to help 🙂
        In regards of your other question, the Riverbed specifications usually do work.
        A small sanity check (I dont know anything about the applications on the WAN or how many Users are located on those sites) if you take 1 Mbit/s divided by 500 concurrent TCP sessions you will have less than 2kbit/s for each connection (optimized TCP is usually not the only traffic). 6 Mbit/s divided by 40´000 is even worse than that. Not sure if this will satisfy any application.

        I dont think those concurrent TCP connection values you got are somewhat realistic.


  2. Renzo

    Hello Pashtuk,

    It is true, I could not realize such a simple check. Thank you very much for the explanation, I will let you know how this story ends. =)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s