I can think of lots of reasons NOT to use an LPAR for a test/development system (i.e. dedicated LPAR memory per LPAR versus VM's management of all memory, real hardware required to connect across LPAR's versus VCTC's and IUCV on VM, easier management of guests under VM from any location versus presence in machine room for LPAR, etc.), but not a lot of reasons NOT to use VM (with the possible exception of this OSA problem, if it turns out to be a VM problem).
I've installed dozens of Linux/390 images (Marrist, SuSE, RedHat) over the past couple of years. All have been as second level guests, and I've never had a single problem attributable to running second level. Morever, by using VM as the hypervisor and virtualizing things, it allows me my most effective use of hardware, memory and network resources. And of course, I can do it all from any location since I'm never needed in the machine room. :) Just my $.02 - but then again I'm an acknowledged VM bigot. Having said that, remember that LPAR is really nothing more than a stripped down version of VM's CP in microcode form. :) Michael Coffin, VM Systems Programmer Internal Revenue Service - Room 6527 1111 Constitution Avenue, N.W. Washington, D.C. 20224 Voice: (202) 927-4188 FAX: (202) 622-3123 [EMAIL PROTECTED] -----Original Message----- From: Vic Cross [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 18, 2002 9:25 AM To: [EMAIL PROTECTED] Subject: Re: NFS pb while using OSA Gigabit at 2nd level of VM On 18.07.2002 at 19:51:26, Elisabeth Terseur <[EMAIL PROTECTED]> wrote: > -and last but not least: I really have to install at second > level of VM.... this is the environment we provide here for tests and > education... I can accept that VM shops traditionally would use second-level systems for testing/training, but it looks like there are some real issues with running Linux (at least the installation systems) as guests of a second-level VM. Not meaning to be too critical, but is the need to run at second-level simply because \"that\'s the way we\'ve always done it around here\"? My suggestion would be to run your second-level testing/training VM at first-level in another LPAR. Since I\'m only a VM apprentice though, there may be additional VM management issues that I\'m not aware of. The other suggestion I can make is to try a kernel with the timer patch applied in your third-level Linuxes. Not sure if this might actually make things worse though... ;) Cheers, Vic Cross -- Vic Cross MACS mailto:[EMAIL PROTECTED] Networking, Linux, on zSeries and S/390
