"Migrating" to bigger disk

[Marcin 'Rambo' Roguski]

Not sure where exactly this belongs, so I"m putting it in general.

I'd like to move my 11.00 to a bigger disk, but without volumes, because they are nemesis of my existence (I'm just tired of constant resizing to keep space requirements).

Is that possible, or I'm better off with installing fresh system on new disk?

[Steven E. Protter]

Shalom,

1) You should install 11.11 or 11.23 on a new disk and migrate all your applications. 11.00 support ends in a few short hours and its nice to have HP to call on problems.

2) If you MUST migrate, I would suggest using make_tape_recovery or make_net_recovery to build and image of the old system. After that you can recover to the new larger disk and adjust filesystem sizes to the new, larger reality.

SEP

[Marcin 'Rambo' Roguski]

Well, that's EXACTLY what I want to avoid, not replicate the volumes and adjust their sizes later, but dump everything with new "volumeless" layout.

[Steven E. Protter]

Shalom again,

I'm going to take another shot at this.

A standard, Linux "style" installation on one gigantic disk volume would avoid the problem of constant resizing of logical volumes.

What you have not made clear up to this point is what you are re-sizing. If its application data areas, the Linux "style" solution would work. There are inherent problems however.

1) Its not systems administration. You set sizes in order to have hard limits on use by one user or appliction.
2) A situation that fills the system means it stops dead, not just the user or application. If an Oracle application in an /oradb filesystem fills up the system lives on. In the one volume format the filesystem that just got filled up is root and thats game over, boot into single user mode, downtime until its fixed time.

The way most of us have done it over the years is t set reasonable sizes on the various logical volumes. Make sure /stand is big enough for a few kernels, make sure /var is big enough for the logs, make sure the application logical volumes are reasonable and can be grown to meet new needs.

Constant resizing is part of what an administrator does, its not fun but thats kind of why we get paid to go to work.

With more details I'd be happy to clarfiy further. I reiterate that getting off of 11.00 is an idea that should be looked at immediately. Unless of course you are the US Navy and can afford to spend endless dollars on special support agreements, as is apparently done to support 10.20 systems on various Naval Warships.

Regards,

SEP

[Marcin 'Rambo' Roguski]

Hiya,

Hehe, that's better :)
OK, so clarifying: yes, system that I'm "administrating" is a lovely, cute B132L, with 4.5 GB disk- and the system is starting to grow out of it (despite of constant resizing- /usr, having 1.2 GB now is 19 MB free, imagine).

As you call it "linux" layout is exactly what I need, cause this system has literally no users (except one ...but don't even start :-p :-D ).

What I'm trying to do is:

create blank, bootable disk, that will be mounted as /, cp files as they are mapped to a new drive (excluding lost+found, of course), reboot and be happy...

[Steven E. Protter]

I now further understand the issue.

If you want to preserve whatever was done to this system, then make_tape_recovery if it has a tape or make_net_recovery to an NFS isntall point will let you preserve the system as it is.

If thats not important and you are willing to reinstall all your applications, then do youself a favor, get 11.11(11i v1) and do a clean install on the larger disk.

If you want to go with the Linux style installation, old school guys like me(I really just immmitate JRF,A.Clay and Bill Hassell, et al) will cring, but you can get away with it.

I'm still in favor of file system sizing. This new 36 GB disk is plenty big and you CAN extend /usr and /opt if you need space. Its just / (root) thats a PITA to extend.

Go with success and happy new year.

Glad I was able to help if only a little bit.

SEP

[Bill Hassell]

You can create a single volume HP-UX system from your Ignite backup tape. Perform the backup, replace the disk and boot off the tape. At that point, you pick the disk volume tab and remove the individual mounpoints. Note that /stand is required -- make it 200 megs and you'll be fine. Once you have removed all the other mountpoints, resize the / mountpoint to encompass the rest of the disk.

Note that small workstations are a minority in the world of HP-UX. It is a tribute to the design of HP-UX that it can scale to a single processor workstation with 128 megs of RAM to a server with 128 processors and 1 terabyte of RAM. Managing diskspace on a single user workstation can indeed be simplified to a single volume, but the same style does not work for multiuser servers.

[Marcin 'Rambo' Roguski]

well, thanks for suggestions: Bill Hassell's suggestion will not work for me because of a trivial obstacle- the workstation is really all I got- just B132L with 11.00 somehow installed.
the only thing I got with it was "Network Node Manager" which was accidentally in CD tray, when the machine arrived to me.

Anyway, meanwhile I reverted to getting /opt as big as it gets (currently 1.56 GB- 900 MB free) and moved stuff to it from /usr/local, leaving just symlinks. removed /tmp, I guess root (300 MB) should be enough for big things to compile.

/opt (/dev/vg00/lvol5 ) : 976243 Kbytes free
/usr (/dev/vg00/lvol7 ) : 380523 Kbytes free
/var (/dev/vg00/lvol8 ) : 220421 Kbytes free
/stand (/dev/vg00/lvol1 ) : 54555 Kbytes free
/ (/dev/vg00/lvol3 ) : 362601 Kbytes free

ought to be enough for everyone :D

[Marcin 'Rambo' Roguski]

LOL, OK- time to revive the thread: got the disk! So today I'm up to clone my disk.

So I'm now giving up towards resizing the volumes, but I still have to clone existing system (and that without Ignite-UX fully installed: there's not make_net_*, make_* etc.)

Somebody on comp.sys.hp.hpux suggested these:

> Add the disk to the vg, mirror all volumes and vgreduce the orig disk.
>
> pvmove (1m)
>
> back up data on old disk, vgreduce disk from vg, add new disk
> (pvcreate, vgcreate/vgextend), lvcreate, newfs, and restore data.

Well, but as far as my understanding goes, that does copy volume group,
but will the cloned disk will actually be bootable?

and: I just had an insane idea: dd, would just that bastardized method of clonning work?

Rambo

[Pete Randall · Accepted solution]

Rambo,

Check this thread, in particular, Clay's answer.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1083682


Pete

[A. Clay Stephenson]

dd will certainly work but there is a flaw in your plan. After reading through all of this, it appears that you want a larger disk. The number of extents and the extent size is set when the VG is first created and thereafer cannot be modified. Almost certainly (and unless specifically overriden) the number of extents and pe size was defaulted and corresponds to a value very near the largest disk in the VG. This means that all of your efforts to add the larger disk to the existing VG will work BUT the usable area of the new disk will be no larger than that of the original. Even if you dd the disk, the LVM meta-data remains the same and you effective size is no larger.

You might consider a plan B and create a new VG (e.g. /dev/vg01) and then move everything except /stand, /, and primary swap to the new VG. Back when I used workstations a lot, I typically set them up so that the OS and standard applications were on one disk and non-standard applications (CAD,CAM,CFD, ...)
and their data were on the secondary disk. This made OS upgrades and patches much cleaner.

[Geoff Wild]

Why not use ignite?

Make an ignite image of your machine, swpa the disks, then ignite restore your image?

Rgds...Geoff

[Marcin 'Rambo' Roguski]

like I said- the previous owner (orange.dx) didn't really care about contents of installation, so Ignite-UX is rather scarcely installed (if even).

Mr. Stephensons advice won't work because of a trivial obstacle- if a secondary drive- it will have to be outside the machine... it just won't fit...

Anyway, what about lvextend: in manpage there's no mention about "ultimate" size of volume group: in fact there's mentioning only about available physical device size.

Anyway #2: it turns out that the Seagate ST39173W doesn't like the FW SCSI in B132L- it simply won't spin, if it does- it's not recognized (it, however, works on AlphaStation- damage certainly excluded). So I guess, this will have to wait- again...

[A. Clay Stephenson]

It sounds as though you are trying to mix HVD and LVD SCSI devices -- and that is a big no-no. In any event, the rule still applies, lvextend, vgextend, XXextend cannot get you past the values that were set in stone when vgcreate was first run.

[Marcin 'Rambo' Roguski]

nope, not that I know of- at least it's not a +, it is supposed to have HVD, and the drive is Wide-SCSI.

[Marcin 'Rambo' Roguski]

Good news everyone, after acquiring SE SCSI drive I finally managed to migrate the system.

Thank you all for valuable pointers and links to relevant posts.

I now have a 3-volume group (stand, swap and root) system that I achieved by using Peggy Fong's idea of creating twin volume group,

I replicated these three, dd' old stuff to stand and root and fsck'd them, mounted and resized newly created root to available space and cp'd the old (/opt, /var, /usr) dir structure.
After that just changed new fstab to incorporate new vg mount points, and behold, my system now resides on a 9 Gig Fireball SE.

Case closed :)

Rambo