F5 rSeries Tenant Capacity Planning: vCPU, Memory and Disk Reference Table (with iSeries Comparison)

Most rSeries sizing questions come down to three numbers: how many vCPUs one tenant can get, how much memory is left after F5OS takes its share, and how much disk the tenants can actually use. F5's own documentation publishes the first two, but the disk side is scattered, and buyers moving from iSeries keep getting surprised by it. This page puts the limits in one table, shows where the iSeries comparison goes wrong, and ends with a sizing checklist you can run before you place an order.

Tenant limits by rSeries model

These figures come from the "Tenant data" table in the F5OS-A tenant management chapter (F5OS 2.0.0). The host SSD column is not in that table; it comes from the hardware specifications on our own product pages.

Three things to keep in mind before you rely on this table:

• The tenant count is a ceiling, not a recommendation. It assumes the smallest tenant image. In F5's image table the full BIG-IP image (ALL-F5OS) is capped at 11 tenants per system and the largest image (T4-F5OS) at 6. An r10900 listed at 36 tenants will not run 36 tenants with all modules provisioned.
• The numbers change between F5OS releases. The r2800 went from one tenant to two in F5OS 1.8.0, and older F5 documentation lists 104 GB of tenant-reservable memory on the r5600 where 2.0.0 lists 108 GB. Read the table for the F5OS version you will actually run.
• Some of the vCPUs on the box are not yours. Our product pages list 6 vCPUs reserved for F5OS on the r5800 and r5900, and 12 vCPUs on the r10000 and r12000 series. The "max vCPUs per tenant" column already accounts for that.

What a single-tenant box really gives you

The smallest platforms are where buyers ask the most questions, because they are sized as one-tenant devices.

• r2600: one tenant, 4 vCPUs. A buyer on F5's DevCentral asked what CPU they could configure on a new r2600, since it provides just one tenant. The platform table answers it: 4 vCPUs, no choice.
• r5600 as a single tenant: a DevCentral poster planning exactly this found they could allocate at most 12 vCPUs, and asked whether the remaining ones were reserved for the base OS. The table shows the per-tenant ceiling on this model is 12, so one r5600 tenant tops out there however few tenants you run.

Core licensing is a separate gate. In one DevCentral thread an engineer believed an r4600 had 16 cores of which 4 were disabled, and asked whether enabling them needs an additional license. That is a licensing question, not a hardware limit; confirm the core entitlement on your quote before you plan the vCPU split.

Memory: how much each vCPU brings with it

F5OS sets a default minimum memory per tenant that scales with the vCPU count. F5's documentation gives these formulas, where the vCPU cores per node are given in multiples of four:

• r2000 and r4000 series: minimum memory = 3 × 1024 × vCPU cores per node (MB)
• r5000, r10000 and r12000 series: minimum memory = (3.5 × 1024 × vCPU cores per node) + 512 (MB)

Worked out for a few common choices (our arithmetic from the formula, not a table printed by F5):

The practical use: eight 4-vCPU tenants on an r5600 would need about 116 GB at the default minimum, more than the 108 GB the platform can hand out. So the "8 tenants" in the table cannot simply be eight 4-vCPU tenants. Tenant count, vCPUs per tenant and memory have to be checked against each other, not one at a time.

Disk: the number buyers trip over

F5 publishes tenant image sizes, but we could not find a per-model "tenant disk you will get" figure in its documentation. The picture below is assembled from F5's image table and from what operators have posted.

F5's tenant image sizes (F5OS 2.0.0):

The BIG-IP virtual disk minimum rises with newer releases (77 GB for 15.1.x in the 2.0.0 document, more for 17.1 and 21.x), so a tenant that fit on an old version may need a larger disk after an upgrade. F5 also warns that on systems with many large tenants the host disk can approach capacity, and the administrator has to monitor it.

What operators report, and where it differs from iSeries:

• A community post from May 2026 describes a customer replacing an iSeries with a 465 GB disk (running LTM, DNS, APM and ASM/AFM, with /config about 75% full) with an rSeries where the space reserved for tenants showed 294 GB in df. The poster's worry was that the new device lacked space for the same module set.
• A 2023 post sizing an r5600 as a single tenant compared default allocations against an i7800: /shared 40 GB vs 15 GB, /var/log 20 GB vs 2.9 GB, /var 3 GB vs 4.5 GB, /config equal at 3.2 GB. The poster asked whether anyone had run short of space by not expanding the tenant disks. Treat these as one operator's numbers from an older release, not as current defaults.
• A 2024 thread on r2600 tenant disk sizing got the answer that the r2600 has a 480 GB drive and that there seems to be a threshold of about 297 GB for tenant disk allocation. That is a community recollection, not an F5 statement.

The pattern across all three is consistent: the SSD on the spec sheet is larger than the space tenants can use. If your current iSeries is more than half full, assume the same configuration will be tight on a smaller rSeries tenant disk until you have measured it.

iSeries to rSeries: what changes for capacity

The planning mistake we see most is carrying iSeries numbers straight across.

• No bare metal. On rSeries everything runs in a tenant on top of F5OS, so the F5OS reservation (vCPUs, memory, disk) is a cost iSeries did not have. A DevCentral reply put it directly: there is no bare-metal installation on rSeries anymore.
• Disk is allocated per tenant. Each tenant gets a virtual disk of a size chosen when it is created. Under-sizing /shared or /var/log at the start is what the forum threads above are about.
• Tenant software versions are restricted. One DevCentral responder wrote that rSeries tenants need TMOS 15.1.x or 17.1.x and that v16 is not supported on rSeries. That was a 2023 reply; check F5's current compatibility information for the version you intend to run.
• Pick the model first, then check the layout. For which rSeries replaces which iSeries, use the iSeries to rSeries replacement map; this page covers whether the replacement fits your tenant layout.

Pre-purchase sizing checklist

1. Write down your current usage, not the datasheet. Get df -h for /shared, /var, /var/log and /config on every iSeries or VE you are replacing, plus real memory and CPU use at peak.
2. Pick the smallest tenant image that fits (T1, T2, ALL or T4) and check the system-wide cap for that image in the table above.
3. Check tenant count, vCPUs per tenant and memory together against the model row. The sum of tenant memory has to stay inside the "memory reservable for tenants" column.
4. Sum the tenant virtual disks and compare them with the host SSD, leaving room for F5OS, images and UCS archives. Expect less usable tenant space than the headline SSD size.
5. Size /shared and /var/log generously at creation, since those are the filesystems operators report running short on.
6. Confirm the F5OS version and the BIG-IP version you will run, because tenant limits and disk minimums moved between releases.
7. Confirm core and module licensing separately with your supplier. A tenant that fits the hardware can still be blocked by a license.

Where this fits in the rest of the rSeries guides

If you are still choosing a model, start with the rSeries model comparison and the EOL replacement guide. For redundant pairs, tenant sizing has to match on both units; see the HA pair migration guide. If your tenants fail to load after the move, the migration troubleshooting guide covers the common errors, and the third-party optics and DAC guide covers the cabling side of the same purchase.

Looking at a specific model? The LTM pages carry the full hardware specifications, for example the LTM r5600 and LTM r10600. If you want us to check a tenant layout against a model before you order, use the quote form on any product page.