I recently ran the OpenVZ script that generates a configuration based on 1/nth of the host. I was a little shocked to see how much memory it was giving to each guest, and then I realised that it wasn't dividing up physical memory, but the combination of physical memory and swap space.

I certainly don't think that this is appropriate, and I am now a little concerned about what OpenVZ providers mean exactly when they offer plans with ???MB of RAM. As a client, if I was allocated a certain amount of "memory" only to find it swapping in and out all the time I would be very annoyed. As a hosting provider I wonder if, by doing what I consider to be the right thing, I am left competing on an uneven field.

In the worst case you could be getting guaranteed RAM that is prone to swapping, and burst RAM that is never available.

I chose to provide guaranteed RAM that there is enough physical memory for, and burst RAM that there is typically enough physical memory for, and certainly enough swap for. By typically, I mean normal operation, only in the event of one host dying (and thus its sibling node taking on both sets of guests while we effect repairs) would all the physical memory be taken up by the alloted guaranteed RAM.

This way everyone can allocate all the way up to the burst all of the time, but it might get a little swappy in an emergency situation.

So unfortunately, in answer to the original question, I would have to say that guaranteed RAM and burst RAM don't by themselves mean a thing. The rest of the story depends on how much of that is real memory, how much can be swap, and by how much both real memory and swap are oversubscribed in different scenarios. If you are considering a hosting company that isn't comfortable with divulging that information it could be a bad sign.