Simple OpenVMS migration

This article describes how to migrate a simple OpenVMS environment from a real Alpha system to AlphaVM. The process is illutrated with an example of a DS10 server migratrion.

The process can be outlined as follows:

Determine your real Alpha configuration.
Save the disks as disk images
Install and configure AlphaVM to reflect your real Alpha configuration as close as possible. The disk images are used in the configuration.
Boot your OpenVMS on AlphaVM.

It is assumed that you have a server accessible via SSH to store the disk images copied in the process of migration. The migration process does not require any modification of the original system.

Detailed instructions:

Download Gentoo Alpha LiveCD image and burn a CD with it.

For instance, it can be downloaded from here, here, or here. The CD will be used as "bootstrap" environment to used to copy disk images.
Determine the system configuration.

In your Alpha SRM prompt type
```
>>> show dev
```
This command will show the configuration of your Alpha system.

For instance on our DS10.
```
>>> show dev
dka0.0.0.0.1.16.0               DKA0                    RZ2CC-KF    5520
dka100.0.0.0.1.16.0             DKA100                  RZ2CC-KF    5520
dqb0.0.1.13.0                   DQB0        Compaq     CRD-8402B    1.03
dva0.0.0.0.0                    DVA0
ewa0.0.0.9.0                    EWA0         00-10-64-30-3F-01
ewb0.0.0.11.0                   EWB0         00-10-64-30-3F-02
pka0.7.0.16.0                   PKA0             SCSI Bus ID 7            
        
```
The system has two hard disks: DKA0 and DKA100. The disk names have the form of DKxnnn.

We have x='a'. It indicates that the disks hang on the SCSI bus of the first SCSI controller. Our system has just one SCSI controller - PKA0 - and one SCSI bus. The letter 'b' would correspond to the second controller PKB0, and so on. The disks attached to PKB0 would be called DKB0, DKB100, etc.

The number nnn encodes the SCSI ID as follows 100 * ID + LUN. Thus, our disks have IDs 0 and 1 and both of them have LUN=0.

The SRM console on some systems would explicitly report the SCSI BUS, ID and LUN.

Check some SRM console variables to determine your boot settings:
```
>>> show bootdef_dev
bootdef_dev                 dka0.0.0.16.0
>>> show boot_osflags
boot_osflags                0,0
>>> show auto_action
auto_action                 RESTART
        
```
Load the Gentoo LiveCD into the CDROM device and boot from it. Your CDROM device name can be seen from the table shown at step 2.

Our DS10 has an IDE CDROM called DQB0. We boot it as follows:
```
>>> boot dqb0
```
If your system has a SCSI CDROM, it will be called something like DKA400. Boot it as follows:
```
>>> boot dka400
```
Linux boot loader will come up with the boot loader prompt. Normally the option 0 is what you need.
```
aboot> 0
```
You can review the available boot options by typing l.

Linux will boot and configure the network using DHCP. Now you have an environment where you have access to your disks and to your network.
Check the disk devices in Linux. SCSI devices have the form of /dev/sda, /dev/sdb, etc.

Our system has two disks DKA0 and DKA100
```
# ls -l /dev/sd*
```
The device names without numbers correspond to the whole disks. The names with numbers correspond to partitions. We will copy the whole disks devices. In our case these devices are /dev/sda for DKA0 and /dev/sdb for DKB0.

IDE devices have the form of /dev/hd*. AlphaVM does not support IDE, but if you have IDE disks, the images can be attached to AlphaVM as SCSI disks.

Copy each of the disks as follows:

dd if=/dev/sda | gzip -9 -c | ssh user@192.168.1.2 "cat > dka0.dd.gz"
dd if=/dev/sdb | gzip -9 -c | ssh user@192.168.1.2 "cat > dka100.dd.gz"

GZIP can be slow on Alpha, especially with -9. You can skip -9.

If your Alpha has a 1GB NIC and you have enough space on the target system, it can be faster to copy without gzip.

dd if=/dev/sda | ssh user@192.168.1.2 "cat > dka0.dd"
dd if=/dev/sdb | ssh user@192.168.1.2 "cat > dka100.dd"

Install AlphaVM. On Windows run the installer and follow its instructions. On Linux unpack the tgz file and run
```
sudo ./install.sh
```
Check the user manual for the details.
Configure the emulator to reflect your system as close as possible. The following pictures on Windows illustrate our configuration.

We set the system to DS10

You may also wish to adjust the number of CPUs, if you emulate a multi-CPU system. AlphaVM-Free supports only a single CPU configuration.

We set the fast JIT2 CPU (AlphaVM-Pro). AlphaVM-Free supports only the basic CPU.

We set 1GB RAM (AlphaVM-Pro). AlphaVM-Free supports up to 512MB.

You may choose to migrate to a system with a different memory size than the original system.

Configure as many SCSI controllers as you need SCSI buses. In our case there is only one bus. There is only one controller configured. In the AlphaVM configuration it is called qla0. It will appear as PKA0 in SRM and OpenVMS.

Configure the disks using SCSI BUS, ID and LUN numbers of the original system. We have: BUS is 0, ID is 0 for DKA0 and 1 for DKA100, LUN is 0 for both disks.

Add as many Ethernet cards as the original Alpha system has.

You may choose to set the MAC address to the same value as on the original system. Some third-party OpenVMS software uses the MAC address to implement license checks. It will fail, if the address is different.

Note however, that if you set the address to the same value as on the original system, and if you try to run both the original system and AlphaVM at the same time on the same subnet, you will get a MAC address conflict.

For AlphaVM-Pro you will also have to specify the AlphaVM license parameters. EmuVM provides these settings when you get the evaluation or the production software. AlphaVM-Free users should ignore the license settings.
Start the emulator. On Windows the launcher will start the Console terminal. On Linux you will have to connect to the console manually.

In the console terminal press Enter. You should see the SRM prompt ">>>".
You may wish to set the SRM variables related to booting of the system. Look how they are set on your original system and set them on AlphaVM to correspond to it.

On AlphaVM you can set the variables in the same way:
```
>>> set bootdef_dev dka0
>>> set boot_osflags 0,0
>>> set auto_action restart
        
```
Setting auto_action to boot automatically is probably not a good idea for the first boot. You may wish to leave it at HALT for the first boot.
Boot the emulator. Choose the boot disk to boot from the boot disk.
```
>>>boot dka0
```
If you have set the bootdef_dev, you may as well just use the boot command without arguments.

OpenVMS should boot like on the original system.

You have migrated your system to the emulator. Congratulations!