Hi Zaxxon,
what kind of apps are you running (DBs, Websphere ...) and are your p5 virtualized or capped
And will your cpu pool be generous or rather low.
I am doing the a lot of sizing for my company - at the moment we are consolidating 38 small p5 frames (550/570ies) into 4 780ies ... what I find is that from a pure performance perspective a few rules of thumb still work perfectly fine - we have generous pools so I do not really care about cpu entitlements when I do the initial setup. If I have a sybase DB, I use one virtual per engine (backup server and repserver count as engines) + 1 as count for virtual cpus, on Oracle I am checking how many parallel processes (not connections) I have running on the server I want to migrate - that will be the amount of parallel threads I want to allow on the new box too - 1 virtual = 4 threads + 1 virtual for the OS. My virtuals are generally worth 0.1 physical cpu - as they can grow to a physical cpu during peaks that is just fine - what is not needed goes back into the pool. Monitor about 4 weeks after go live closely and than amend the amount of entitled cpu to what you usually need (so in average, NOT during peaks) and that is what they get permanently. Regarding memory - well its pretty much the same.
For websphere boxes we usually go with half as many virtuals as we were using on p5. Again - monitor closely and amend if required.
In my experience you have usually a lot of cpus in the pool and most frames do not have the peak times of all their lpars same time so you should usually be good.
For DBs you can go if you like as well another way: p5 to p6 = 3:2, p5 to p7 = 7:4 - that is what our engineering came up with - they assume high frame usage and small pool
I have the official IBM numbers in the office - can post tomorrow ...
Hope that helps
regards
zxmaus