Transfer K420 operating system to K360 system

[Roy Fernando]

We have K420 system running HP-UX 10.20 operating system. We use fbackup to backup operating system and data every day. Recently we bought new K360 system. I want to move K420 operating system and all the data to the new K360 system. What is the bast way to transfer K420 operating system to K360 system?

[Patrick Wessel]

Roy,

the best way is to move all disks. The K420 and K360 have the same address shema.

[Roy Fernando]

Patrick,

Thanks for the reply. We have 2 Gb disk within K420. We bought new K360 with 2 internal 9 Gb disk. I do not want to transfer 2Gb disk to K360 system

[Alex_7]

Roy,

try with MirrorUX, boot K360 from 2Gb K420 HDD and mirror logical volumes.

alex.

[Shyam Kishore]

Hi Fernando,

For your case best way is just take back up and restore it in new server as your data i in only 2 * 2 GB disks.

All the best.

-Shyam

[melvyn burnard]

One way to do this may be to take a look at Ignite/UX, and create an image to download onto the new server.
If the data disks are external, and on separate vg's from vg00, then you just move them, and import them to the new server

[Tim Malnati]

Mirrordisk works well but it's an addon product that's a bit expensive. I recommend it for all production machines though. Basically you need to mirror all of vg00 over to a spare hot swap drive, and move that drive to the new machine. Make sure that pvcreate the drive to be bootable and mirror the boot area with lvlnboot. My guess is that you want to use the internal drives on the new machine for vg00, so you'll need to do the process again on the new machine. A potential problem here is that you may want/need to change around the sizes of your root file systems in which case your stuck with doing it the old fashioned way in single user unless you have advanced JFS.

Ignite is another option that works well, but unfortunately has a learning curve. It allows (almost demands) that you reallocate file system sizes when your building the new box. It also does not copy everything over by default.

It seems that you are probably in somewhat of a hurry to get this done. My best suggestion is that you contract some time with your local HP SE. This type of thing is an everyday evolution for these people, so they can turn it around very quickly.

[Victor BERRIDGE]

Roy
You havent said how is configured your K4XX, I mean is everything on one 2 GB disk, or is your 2 Gb disk only the vg00..
You could have vg01 on another internal disk or on a external cabinet.
This changes a lot on how I would proceed.
As mentionned previously if all is on one disk that is vg00, then make_recovery is fine.
If you had a second internal disk (vg01) then you would use a make_recovery (for vg00) and a fbackup (for vg01) tape after having recreated vg01.
If you had the rest on a external cabinet then you would use a make_recovery (vg00) and do an export / importvg...
all the best
Victor

[Dragan Krnic]

What I usually do to clone a system to a compatible hardware is have the disk for the new machine somehow accessible, via SCSI or network, and then do the following:

Create a volume group on the new disc, make it bootable and partition it as desired, usually a boot volume of 68 MB a swap volume not exceeding 2 GB together with boot and the rest is root. (no /usr, /home, /tmp or whatever - it only creates problems later, when any one of these gets full).

Transfer /stand into lvol1 (boot), transfer all from other original system directories to lvol3 (/) using a command of the form:
cd /future-lvol3-mount-dir
rexec orig "/etc/dump 0dsbf 6250 999990 32 - /dev/vg00/rlvol?" | restore rf -k
or similar (dump is fast, copies all file atributes, devices, sockets, hard and soft links and what not, use vxdump for jfs)

The boot, root, swap and dumps have to be linked accordingly with lvlnboot.

The 12 bytes in the /stand/rootconf file have to be edited: leave 1st 4 bytes ("0xDEADBEEF") unchanged, 2nd 4 bytes should be long integer specifying offset of the root volume in KB, last 4 bytes a long integer specifying root size in KB.

When first booting off the disk use maintenance mode ("hpux -lm") at ISL> prompt). Remove vg00 with vgexport, create a new one, import the boot disk, activate vg00, remove lvlink with "lvrmboot -r vg00", relink as initially and reboot in single user mode ("hpux -is" at ISL>prompt) to check if some slight differences in device namings need to be retouched before proceeding to "init 3".

[Roy Fernando]

Thank you very much for your ansers. I am planning to use Ignite/UX
Kind Regrads,
Roy