I think one of the biggest benefits of "slabbing" is mobility. For example: at one point we had a cPanel server that was an OpenVZ VPS, when it outgrew the node it was on I created a KVM VPS with more resources and just did a vzmigrate of the cPanel OpenVZ VPS from the OpenVZ node to the KVM VPS. KVM, Xen, and VMware allow for migrations similar to this (although not a simple one-liner) so having an OpenVZ node on one of them might make migrations easier if say you need to replace a stick of RAM or you want to upgrade the hardware without downtime. You can just move a single VPS instead of all of the clients that are hosted on it.
Migrating a "slab" wouldn't necessarily be any faster than doing a mass openvz migrate via a script that would migrate each and every VPS in an automated fashion (we upgraded about 200 clients/containers on Friday entirely automated)
My understanding is much above 5k processes OpenVZ performance goes south quickly. So, commonly slabbed to work around this with multiple process pools.
Stories about some of these slab workarounds involve rather puny servers (i.e. 32GB of RAM) with upwards of 4 7-8GB slabs.
It certainly does in public blow up you "server" count. So long as everyone stops paying attention and doesn't notice 4 nodes down at the same time, every time, the game goes on.
I can see slabbing being necessary to facilitate the very small plans (i.e. 128MB and less) in any real quantity.
I'm not entirely sure how true this is. The limit can't be 5k, our newer and larger servers at capacity are over this "limit" you speak of.
If there IS a process limit, and we simply haven't hit it yet, then offering small ram packages (BlueVM did 96MB packages recently iirc?) would make sense in a slabbed setup, but still rather miss-leading as far as a company boasting about total node count.
If there is a magical process limit for OpenVZ, then slabbing for these smaller packages makes sense, and MAYBE larger systems like Dual E5's with 128gb+ memory, but it would have zero place on lower systems such as E3's with 32GB of memory.
Edit:
This is direct from the Openvz site:
There is a restriction on the total number of processes in the system. More than about 16000 processes start to cause poor responsiveness of the system, worsening when the number grows. Total number of processes exceeding 32000 is very likely to cause hang of the system.
Note that in practice the number of processes is usually less. Each process consumes some memory, and the available memory and the "low memory" (see
“Low memory”) limit the number of processes to lower values. With typical processes, it is normal to be able to run only up to 8000 processes in a system.
http://openvz.org/UBC_primary_parameters
In short, even with silly overselling, you'll hit CPU limitations on E3's in particular long before you hit a process limit (we're nowhere close on our new nodes, and these hold roughly 2-3x what our old nodes are capable of holding)
