Move system disk - Itanium

[Peter Zeiszler]

I currently have 8.3 installed on an Itanium using local disks. I just got disks on the SAN allocated to the cluster. I am trying to migrate the system disk to the SAN disk.

Here is what I did:
$ init/header='file_size'/nohigh/owner=system/struc=5 'disk' prod_sys_I2
$!
$ mount/over=id 'disk'
$!
$ backup/fast/ignore=(nobackup,interlock)/exclude=([sys*.syscommon...]*.*) dsa50:[000000...]*.* -
'disk'[*...]*.*/by_owner=orig/nolog
$!--(First remove the syscommon directory the backup utility created)--!
$ delete 'disk'[sys0]syscommon.dir.1/log
$ set file/enter='disk'[sys0]syscommon.dir 'disk'[000000]vms$common.dir
$set bootblock /i64
(run SYS$SETBOOT.EXE - tried this command too)

(there was another executable I ran too --
I was able to boot the disk but the IP stack didn't come up. I went into tcpip$config, core, interfaces and it bombed out - wouldn't let me choose a device there.

-------- error message ------
Configured address file error
%TYPE-W-SEARCHFAIL, error searching for SYS$COMMON:[SYSMGR]TCPIP$CONF_ADDR_SCRATCH.TXT;
-RMS-E-FNF, file not found
---------------------------------

I am trying to do the same commands today with the system minimum booted.

I do use shadowing but the local system disk is a different size than the SAN disk.

Any other ideas to get this system disk migrated to the SAN?

[Bill Hall · Accepted solution]

Peter,

I would never have thought to try to replicate a boot disk that way. You should do an image backup of the existing system disk to the SAN disk. Run boot_options.com to change the efi boot menu to use the SAN disk.

I'd also recommend setting the cluster size to at least 16 (or 32, 64 etc.).
$init/cluster=16/header='file_size'/nohigh/owner=system/struc=5 'disk' prod_sys_I2
$ mount/for 'disk'
$backup/ignor=interl dsa50:/image 'disk'/noinit
$@sys$manager:boot_options

Be sure to mount the target 'disk' /foreign and qualify the backup target with /noinitialize.

Bill

[Jan van den Ende]

Peter,

I fully agree with Bill. I am mildly suprised that it even got as far as trying to het TCPIP running!
>>>
I do use shadowing but the local system disk is a different size than the SAN disk.
<<<
That in itself should not be a problem (unless the SAN disk is _smaller_ than the local disk...) but, most likely your local disk will not be very optimal for SAN.
AFAIK the INIT still defaults to a clustersixe of 3 (except VERY small disks), and you REALLY want a multiple of 16 (maybe, just maybe 8, if almost ONLY files of lesser sizes are to populate the disk).

And in the INIT I would NOT omit to specify /LIMIT=<1 Tbyte>. The penalty is low, and otherwise the potential future regrets are NOT!

Obviously you are planning to boot from the SAN drive, so some downtime now will not be too awfull. I would boot from CD to do the BACKUP, that ensures a clean copy.

Success.

Proost.

Have one on me.

jpe

[Peter Zeiszler]

I have to drive to system to install CD into system. So was trying it remotely.

The Disk backups setup I came up with for moving system disks with Multinet systems and multiple roots (sys0, sys1, etc). With Alpha systems just do writeboot and it works like a charm.

The internal system disk is actually larger than the SAN disk. We didn't do partitions on the internal disk so its got everything - system, applications, users, etc.
The final configuration is to migrate the data to SAN and merge it with an existing Alpha cluster. Then we will migrate the applications to Itanium while just mounting the disks on the Itanium. Then it should be a quicker cutover moving completely to the Itanium.

The SAN disk is the ideal because we have the systems split across sites. This also gives us ability to add another disk for shadowing and breaking out a good copy (useful when doing patches and upgrades)

[Peter Zeiszler]

Forgot to add
Cluster default for ODS-5 is 16 for the init command.

------------------
INITIALIZE

/CLUSTER_SIZE

/CLUSTER_SIZE=number-of-blocks

Defines, for disk volumes, the minimum allocation unit in blocks.
The maximum size you can specify for a volume is 16380 blocks, or
1/50th the volume size, whichever is smaller.

For Files-11 On-Disk Structure Level 5 (ODS-5) disks, the default
cluster size is 16. In this case the minimum value allowed by the
following equation is applied:
-----------------------------

[Jan van den Ende]

Peter,

>>>
I have to drive to system to install CD into system. So was trying it remotely.
<<<
To me, that sounds like a reasonable argument. Be even in that case, I would MOUNT/FOREIGN the target drive, and BACKUP.IMAGE/IGNORE=INTER
Make sure you are yhe ONLY user on the system, and there are NO batches running during the BACKUP, and you are pretty much safe
(Hoff, I know. /IGNOER=INTER should be interpreted as /ALLOW=CORRUPTION, but with the aforementioned precautions, I am not afraid to do it).

Proost.

Have one on me.

jpe

[Peter Zeiszler]

Well this afternoon I might get another hour window to "migrate" to SAN. Will try the min boot, backup/image, etc.

I will post results here.

[Jon Pinkley]

While I was entering this response, there have been several new notes added, so some of this is redundant to what's been entered.

You stated that the SAN disk is smaller than the current local storage. I assumed that was the reason you did not using an IMAGE backup. However, your original command was not excluding anything but the syscommon directories.

If there is enough room on the output volume to hold everything, then you should use an image backup, as it will only copy the files once. Then after the backup is complete, you can delete the application directories from the system disk (using something like DFU for efficiency)

With 8.3 (actually 7.3-2 and above) Host Based Volume Shadowing supports shadowing different sized shadow members. The DSA device will be the size of the smallest member. Therefore you can add a member that is larger than the existing shadow virtual unit, and the extra will be ignored. (Update: this will not work for you, because the SAN is smaller than the existing disk).

If you think you will ever increase the size of the volume (easy to do with SAN storage like an EVA), then I would also use the /LIMIT and /MAXIMUM_FILES option to preallocate the BITMAP.SYS file and the index file header bitmaps. And as Bill Hall said, an IMAGE backup is the way to do this.

And make sure you specify the /noinitialize when doing the backup (As Bill Hall's example shows), or all your carefully chosen values will be replaced with what was on the source disk. If you are changing the clustersize to something that is not a multiple of the original size, I also recommend the use of /truncate, otherwise the output file sizes will be based on the allocated size of the input file, not the used size.

Example: Source disk clustersize = 9, destination disk clustersize=16

Input file size 10/18 Output file size without specifying /truncate 10/32 (next multiple of 16 => 18)

Input filesize 10/18 Output file size when specifying /truncate 10/16 (next multiple of 16 => 10)

Good Luck,

Jon

[Peter Zeiszler]

The backup image worked.

Helped when I moved data to another disk, moved pagefile, etc. Gave me plenty of room on the disk.

Next step in migration is going to be moving a root to new disk - might just recreate the root on the new disk for the other system.

Thanks everyone for the help.