> V=R - then why run under VM at all? As an old MVS production hand, > I have to at least smirk at that ;)
As an old VM hand, I can understand the why, though I doubt I will succeed in conveying it. But here goes. I see little value in LPAR other than marketting: "it's a hardware feecher, so you don't have the cost of VM" or more significantly to foster continued sibling rivalry from MVS. > Why not VM for those things appropriate to VM > and an LPAR or LPARs where appropriate, talking back and forth using > hipersockets? That would be great. It rarely happens. As things work out, VM and LPAR are parts of, and sometimes also objectives of, office politic agendas. > One of the configurations I see tried more and more often is a VM > environment of a lot of small linux EC's to act as web servers and routers > connected to one very large data base server (VLDB) (Linux LPAR, MVS LPAR > or pSeries). Its these VLDB servers I'm talking about. > > These VLDB servers under Linux could use 2-10 GB of real memory and have > hundred's of GB's or Terabytes of data at 15 ms access times or less. In > these cases, why incur any VM? ... In these cases, a V=F preferred guest is too close to "native" to not use VM. And VM lets you retain the control option of turning OFF the V=F if and when you need to. VM gives you greater control over all DASD so that you could bring up a test MVS more readily. > Obviously, the issues of cost, performance, throughput, availability, and > reliability, need to be stewed into the equation, but don't discount BIG > penguins as an alternative. I wouldn't say that. But I also wouldn't say that a "BIG penguin" should not run on VM. > Regards, Jim > Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs > t/l 543-4021, 408-463-4021, [EMAIL PROTECTED] > *** Grace Happens *** Well ... yeah ... when pride doesn't. -- R;
