SUMMARY: Cloning a system with fiber channel SDS mirrored bootdisk

(sorry, 1st copy was not titled "summary" which seems to
have confused people)

SUMMARY : Cloning a system with SDS mirrored bootdisk
          with reference to fiber channel.

The initial query:

> I'm configuring two 280R machines with mirrored boot disks -
> these disks are fiber channel. The systems run Solaris 9
> with latest patch sets.
>
> I'm rather nervous about the break-mirror and swap disks
> approach to cloning the system on to the 2nd machine,
> specifically with reference to the fiber channel links
> to the disks which will be in /dev and the role of the
> nvram devaliases.
>
> Does anyone have notes on achieving this? Is it just a matter
> of making sure that the drive being used to do the copy is in
> the same slot as on the host system?


The responses were mostly "I'm out of the office" e-mails and
copies of the "MS Support" virus mail, but within all that crap
lay some useful tips (reproduced here as the procedure seems
to change depending on your FC platform):


Drew Skinner responded:
> Done this many a time. Just boot -r to ensure that the drive 
> is correctly seen. You really only need to worry about the 
> WWN (world wide name) for the FCAL drive as the Sun box likes
> to stick that into the boot line. A couple of minutes at the
> OK prompt and you can set the system to boot from the correct
> drive.
>
> I normally edit the nvram so as to have multiple boot disks.
> On a v880 I end up with something like:
> 
> host#eeprom nvramrc
> 
> nvramrc=devalias altboot /pci@8,600000/SUNW,qlc@2/fp@0,0/disk@3,0
> devalias bootdisk /pci@8,600000/SUNW,qlc@2/fp@0,0/disk@0,0
> 
> On a v280 the boot-device is usually listed this way:
> 
> boot-device=/pci@8,600000/SUNW,qlc@4/fp@0,0/disk@w21000004cf2282a5,0:a
>
> Pay particular attention to the following:       ^^^^^^^^^^^^^^^^^^^^^
> 
> This is what you need to set correctly (unique to each disk) on
> the freshly transplanted system.


Stan Pietkiewicz responded :
> I've recently gone through a similar exercise, only without SDS
> mirrored disks.....
> 
> What I've done is basically:
> 1) Use ufsdump to backup the entire root drive on the source
>    server (all filesystems on the disk)
> 2) Boot the target server from the Solaris 8 software 1 of 2
>    CD (not the install CD)
> 3) Restore from tape onto the root drive of the target (clone).
>    I made sure the root drive was the same (drive 0) in both cases.
>    Run installboot pointing at the root drive.
> 4) Wipe out the restored /dev/dsk/ and /dev/rdsk hierarchy on
>    the clone drive. Run the command: devfsadm -c disk -r /a 
>    (assuming you've mounted the target drive as /a) to rebuild the
>    device files on the target root drive.
> 5) Find out the WWN of the root drive in the clone machine and
>    edit the restored /etc/path_to_inst to include that WWN as
>    instance 0 of the device "sd".
> 6) Do a reconfiguration boot, and change the identity (hostname,
>    IP,..) of the clone machine.
>
> The SDS mirror may change things to the point where this wouldn't
> work in your case.  The only thing I had to do at the OBP level, 
> other than ensure the device aliases were pointing at the right
> devices, was change the "boot-device" variable to "disk disk1".


Mike Demarco responded :
> You can clone the disk but what you will have to do is to first 
> boot the new system from a CD and copy the /tmp/dev /tmp/devices 
> to the cloned disk. This will give you the proper device path to
> the migrated disk wwn. How stupid it was for Sun to use the wwn
> in the device tree.


The approach I used combined the suggestions into something which
I hope represents the shortest path in my case on the 280R:

1) Break mirror on second disk of source system.
2) Insert as first disk on destination system.
   (NB: this is from a bootable mirror disk!)
3) boot -s cdrom from Solaris 9 software CD 1
4) Mount newly inserted /dev/dsk/cNt0d0s0 to a mount point in /tmp
5) devfsadm -c disk -r /tmp/mountpoint
6) Restart single user from HD and rebuild SDS mirrors, syncing
   and replacing.

Not too hairy, but pretty confusing :)

Thanks to Drew, Mike and Stan.

--
Tony Howat
UNIX Network Administrator
The London Institute
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers