On 9/6/06, Vic Cross <[EMAIL PROTECTED]> wrote:
When you're sharing DASD, you don't have different device numbers to refer to a pack from different LPARs, right...? Why is it a bad idea for OSAs?
They deserve different treatment because they work differently and are used differently. In the case of the OSA Express, the microcode itself uses the tuple of LPAR number and unit number as a unique handle. So if you define in each LPAR devices on the same OSA chpid as E000-E0FF, each LPAR could activate the E000-E002 tripod and not bother the others (as long as the total active tripods stays under the defined limit for the type of card). I honestly don't see anything wrong with each z/VM TCP/IP stack access that OSA at the same address. The old OSA-2 was kind of different because you needed to tell it in the OAT which of the 16 IP addresses was active in what LPAR, without the ability to map them. With DASD devices, the control unit does not do this kind of tricks. When you define a string of DASD devices on a control unit to different LPARs, then each of the LPARs will see the *same* device there. If you can, it probably makes sense to have the same DASD at each LPAR at the same address. Sometimes you actually have two LPARs both use the same device (e.g. a shared RACF database) and sometimes devices are just picked on demand out of the pool and get a label that makes it clear which LPAR is using it. For the storage and operations folks it may be handy to have the same device address in each LPAR, but the systems mainly deal with the volser to identify the volume (with PAV enabled on the control unit you will see the same volser on different device address anyway). When you run a lot of 2nd level guests with dedicated devices, it becomes less attractive to stick to that "same address" approach (and do the mapping in the directory rather than in your head). If different storage teams are involved, you may want to use the IOCDS to restrict one LPAR in getting to the devices of the other, but still retain center-unique addresses for the volumes. If you do manual tape setup (with units possibly shared between LPARs and systems) you will eventually wish yourself in Alan's lake when you define the same unit with different address on the systems. One shop I visited decided to re-map their local 3270 devices in the IOCDS. The effect was that local terminal 0040 was available in each LPAR, and they were different consoles at the Operations desk. This was convenient for the people who moved images between machines (no need to change the system configuration file when you re-arrange the images or Operations desk). However, it did confuse some operators (and me) because consoles were not anymore identified by their device address. But they also used KVM switches on them so an operator in a hurry is pretty much Russian Roulette... Bottom line: You want to do the mapping where you can manage it best. That depends on the type of change, split of responsibilities in the team, and possibly skills. -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
