> I'm surprised that 100+mips isn't enough to run what I've laid out, > given dynamically weighting for CP and dynamic storage > reconfiguration.
If all you're running is test instances, it might be enough. The H50 isn't that big of a box, and while you could technically do this on a P390, you won't like it much. > 1. Will VM give me more flexibility when I carve up the real memory > to the individual guests (vs multiple lpars using > dynamic storage > reconfiguration). Yes. You could give each guest a virtual memory size which is the same as the real memory size if you have sufficient paging space, etc. You don't have to dedicate real storage to guests -- let CP worry about managing real storage. Give each guest what it wants/needs, and let CP sort it out on the real level. Much simpler than the LPAR setup. > Can I add/delete real memory to guests on the fly? Easier to give the virtual machine more virtual storage than it needs and then let CP worry about it. > 2. Same question for CP ? Not really necessary. CP owns everything real in this environment. For the guests, there's no requirement that real = virtual in this environment, although naturally performance will be better if you don't have to overcommit. It'll still be good, though. > 3. Are these two Linux guests suggested for the purpose of > routing(to the > other guests) > DMZ, firewall, etc. as you have mentioned in the past? Yep. It also allows the guests to come and go at will w/o disrupting the rest of the world, esp if you start building guest farms or having test systems appear and disappear. It makes the routing in the exterior network simpler if your network guys can depend on the Linux guests being there all the time on the physical adapters, and all the other guests are sitting on virtual adapters behind the Linux systems. -- they can statically route a couple of subnets via the Linux systems, and then they can go away and leave you to manage the allocation of that stuff internally. Let's you do all kinds of stuff with routing and VIPA, etc w/o the network guys having to get involved every time. -- db
