From: Craig Collins <[EMAIL PROTECTED]> To: LINUX-390@VM.MARIST.EDU Date: 23/06/2008 17.36 Subject: Synchronous remote copy FCP disk and DR
< We're wondering if anyone has any experience with disaster recovery of the < zLinux guests when using FCP disk. For a variety of reasons, we chose to < use the NPIV FCP disk instead of CKD for our Linux guests, including boot < ...snip < Since the serial number for the remote subsystem is different from the < primary, when we split the pair and try to boot from the remote disk, the < intial boot process starts but we eventually get 'Waiting for device < /dev/disk/by-id/scsi-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-part4 to appear:' and < this references the boot LUN on the primary disk. It exits to the shell at < that point. < ...snip Craig, I had some sort of similar problem some times ago, even thought it was on CKD disk... anyway, I was able to bypass this problem, issuing following command at boot time, using CMS console: #cp vi vmsg 1 dasd=xxx root=/dev/dasdyy (where xxx is address of boot disk and root= references device) Hope this helps. Ciao. _________________________________________________________________________ Paolo Cacciari IBM Italia S.p.A. Business Continuity and Resiliency Services, IBM Global Services - South Region, EMEA Via Darwin 85, 20019 Settimo Milanese(MI) ? Italy - MISET001 "The goal is to be prepared for a disaster not to continually plan for a successful test" * [EMAIL PROTECTED] ( + 39 051 41.36799 Mobile: + 39 335 6287584 7 + 39 02 596.23288 Fax BO: + 39 051 406052 Please consider the environment before printing this e-mail notice From: Craig Collins <[EMAIL PROTECTED]> To: LINUX-390@VM.MARIST.EDU Date: 23/06/2008 17.36 Subject: Synchronous remote copy FCP disk and DR We're wondering if anyone has any experience with disaster recovery of the zLinux guests when using FCP disk. For a variety of reasons, we chose to use the NPIV FCP disk instead of CKD for our Linux guests, including boot LUNs. The disk is synchronously remote copied between data centers. As part of our disaster recovery planning, we started to think about being able to boot off of the mirrored copy of the LUNs. When we built our guest to test DR with, we make both the primary LUNs and what will be the remote copy LUNs active to the guest and define them within Linux. We then made the remote copy LUNs unavailable to the guest by synchronizing the primary and remote copy LUNs. We made updates, shutdown the guest, split the disk, changed the switch zoning so that the primary disk was unavailable and only the disaster recovery disk was detected. It appears that the fstab entries, zipl.conf, bootmapper, and likely other configuration items, use the subsystem serial number as part of the identification for the partitions on the FCP disk in SLES10. Since the serial number for the remote subsystem is different from the primary, when we split the pair and try to boot from the remote disk, the intial boot process starts but we eventually get 'Waiting for device /dev/disk/by-id/scsi-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-part4 to appear:' and this references the boot LUN on the primary disk. It exits to the shell at that point. If anyone else has already gone through this and knows all of the configuration items we need to update to make this work, we would appreciate the information so we don't have to reinvent the wheel. If not, we'll keep working through this and share what we figure out with the list if anyone is interested. Craig Collins State of WI ---------------------------------------------------------------------- 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 IBM Italia S.p.A. Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) Cap. Soc. euro 361.550.000 C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153 Società con Azionista Unico Società soggetta all?attività di direzione e coordinamento di International Business Machines Corporation (Salvo che sia diversamente indicato sopra / Unless stated otherwise above)
<<image/gif>>
