Table of Contents

Introduction

This section describes how to migrate your Alpha system to CHARON-AXP. We will use a sample AlphaServer ES40 system running OpenVMS to demonstrate the migration procedure. The process is similar for all CHARON-AXP models.

Creating CHARON Virtual Machine

As a first step it is required to create a CHARON Virtual Machine (VM) using the CHARON Virtual Machine Manager in the following way:

Press the "Create VM from Template" button:

Specify the Alpha model to be emulated and the name of the VM then press the "Create" button:

The VM will be created:

Select the VM from the left pane and switch to the "VM Configuration" tab.

In order to reproduce the target Alpha configuration, press the "Edit Configuration file" button:

Alternatively it is possible to select the target CHARON VM and press the "Edit Configuration" button.

Collecting information about the source OpenVMS system

The purpose of this step is to collect the exact configuration of the Alpha hardware in order to create the CHARON VM configuration file.

Turn on the source Alpha system. At the ">>>" prompt, issue the "show device" command:

>>>show device

sys0.0.0.0.0 SYS0 System ROOT Device
ewa0.0.0.1.1 EWA0 F8-D1-11-00-67-E6
pka0.0.0.2.1 PKA0 Q-Logic/ISP PCI SCSI HBA
pga0.0.0.3.1 PGA0 WWN 1000-0000-0248-C550
pqa0.0.0.15.0 PQA0 ALi 1553C Integrated IDE Controller
pqb0.0.1.15.0 PQB0 ALi 1553C Integrated IDE Controller
dqa0.0.0.15.0 DQA0 TSSTcorpCDDVDW SH-222BB
dka0.0.0.2.1 DKA0 DEC RZ28 (C)DEC
dka100.1.0.2.1 DKA100 DEC RZ22 (C)DEC
dka200.2.0.2.1 DKA200 DEC RZ23 (C)DEC
mka600.6.0.2.1 MKA600 Virtual SCSI Tape

>>>

To get more detailed information, boot OpenVMS and issue the "show device /full" command:

$ show device /full

Disk PFCAXP$DKA0:, device type RZ28, is online, mounted, file-oriented device,
shareable, available to cluster, error logging is enabled.
...

Disk PFCAXP$DKA100:, device type RZ22, is online, file-oriented device,
shareable, available to cluster, error logging is enabled.
...

Disk PFCAXP$DKA200:, device type RZ23, is online, file-oriented device,
shareable, available to cluster, error logging is enabled.
...

Disk PFCAXP$DQA0:, device type TSSTcorpCDDVDW SH-222BB, is online, file-oriented
device, shareable, available to cluster, error logging is enabled.
...

Disk $1$DGA0: (PFCAXP), device type RZ24, is online, file-oriented device,
shareable, available to cluster, error logging is enabled.
...

Magtape PFCAXP$MKA600:, device type Virtual SCSI Tape, is online, file-oriented
device, available to cluster, error logging is enabled, device supports
fastskip (per_io).
...

Terminal OPA0:, device type VT102, is online, record-oriented device, carriage
control.
...

Device EWA0:, device type DE500, is online, network device, device is a template
only.
...

Device FGA0:, device type KGPSA Fibre Channel, is online, shareable, error
logging is enabled.
...

Device PGA0:, device type SCSI FCP, is online, error logging is enabled.

...

Device PKA0:, device type Qlogic ISP1020 SCSI port, is online, error logging is
enabled.
...

Device $1$GGA32767:, device type Generic SCSI device, is online, shareable.

$

If Tru64 UNIX V5 is running on the host system, it is recommended to use the following commands to get information on the host configuration:

Command	Description
`#/sbin/hwmgr view devices`	Get detailed information about the host hardware configuration
`#/sbin/hwmgr show scsi`	Get specific information about the host SCSI controllers and attached disks
`#/sbin/hwmgr view hierarchy`	Get information about the host controllers

Please refer to the Tru64 UNIX User's Guide for more details.

The source Alpha peripheral configuration in this example is:

Controller	Devices on controller	Description
KZPBA	-DKA0 (RZ28) -DKA100 (RZ22) -DKA200 (RZ23) -MKA600 (tape)	SCSI disk/tape controller
KGPSA-CA	-DGA0 (RZ24)	FC disk controller
OPA0		System console
TSSTcorpCDDVDW SH-222BB	-DQA0	IDE CD-ROM controller
EWA0		Network interface, MAC address: F8-D1-11-00-67-E6

Now collect some general information about the AlphaServer ES40 system:

>>>show cpu /full

System: PFCAXP, AlphaServer ES40 6/667

SMP execlet = 3 : Enabled : Streamlined.
Config tree = None
Primary CPU = 0
HWRPB CPUs = 4
Page Size = 8192
Revision Code =
Serial Number = SN01234567
Default CPU Capabilities:
System: QUORUM RUN
Default Process Capabilities:
System: QUORUM RUN

....

>>>

>>>show mem

System Memory Resources on 5-FEB-2018 09:29:16.42

Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (512.00MB) 65536 56496 8610 430

...

>>>

So the collected information about the AlphaServer ES40 system is:

Component	Value
System Type	AlphaServer ES40 6/667
Serial Number	SN01234567
Number of CPUs	4
System memory	512 Mb

In some particular situations it is also important to know the exact placement of all the peripheral devices on the Alpha PCI bus. To do so, issue the "show config" command at the SRM prompt (>>>) on the Alpha console. For example:

>>>show config

...

PCI Bus

Bus 00 Slot 03: DECchip 21142 Network Controller
ewa0.0.0.3.0 00-00-F8-03-9A-6D

Bus 00 Slot 07: Cypress PCI Peripheral Controller

Bus 00 Slot 07: Function 1: PCI IDE

Bus 00 Slot 07: Function 2: PCI IDE

Bus 00 Slot 07: PCI USB

Bus 00 Slot 08: DECchip 21052 PCI to PCI Bridge

Bus 01 Slot 08: ISP1040 Scsi Controller
pka0.7.0.1008.0 SCSI Bus ID 7
dka0.0.0.1008.0 RZ2DD-KS
dka400.4.0.1008.0 RRD45

>>>

The "show config" command collects the following information of placement of peripheral devices on the PCI bus:

Bus number
Slot number
Function number

To find out the exact types of controllers and other useful information refer to the source Alpha system documentation.

Creation of the CHARON-AXP configuration file

Using the above information, the following parameters and values can be set in the configuration file:

#
# AlphaServer model: AlphaServer ES40 6/667
#

set session hw_model = AlphaServer_ES40
set ace cpu_architecture = EV67
set rom dsrdb[0] = 1820 system_name = "AlphaServer ES40 6/667"

...

#
# Override default System Serial Number, set it to "SN01234567"
#

set rom system_serial_number = SN01234567

#
# Specify RAM size: 512 Mb
#

set ram size=512

#
# Map OPA0 console to "Putty" terminal emulator (included in CHARON-AXP kit)
#

set COM1 alias = OPA0 port = 10003 application = "putty -load OPA0 -P 10003"

#
# Ð¡onnect the emulator's DQA0 to the host's ATAPI CD/DVD-ROM drive.
#

set ide container="\\.\CdRom0"

#
# Load optional DE500BA PCI Ethernet Adapter (EWA0) and map it to the "Charon" host network interface
#

load DE500BA/dec21x4x EWA interface=EWA0
load packet_port/chnetwrk EWA0 interface="connection:Charon"

#
# Load DEC-KZPBA SCSI controller and map it to 3 disk containers and 1 tape container
#

load KZPBA PKA scsi_id = 7

set PKA container[0] = "C:\My disks\bootable.vdisk"
set PKA container[100] = "C:\My disks\RZ22.vdisk"
set PKA container[200] = "C:\My disks\RZ23.vdisk"

set PKA container[600] = "C:\My tapes\my_tape.vtape"

#
# Load DEC-KGPSA-CA PCI FC adapter and map it to a disk container
#

load KGPSA FGA

set FGA container[0] = "C:\My disks\RZ24.vdisk"

...

Making disk images

In our example, the mapping of the KZPBA SCSI controller include disk and tape images. The tape images have not to be manually created whereas the disk images have to be created as described below.

Our example creates disk images of the original physical type. In reality, this step is the best opportunity in the migration to provision larger disks to get extra storage space.

Create special directories for storing the disk and tape images. The created directories are referenced in the sample configuration file above.

...> cd C:

\
C:\> mkdir "My disks"

C:\> mkdir "My tapes"

This operation can also be done using Windows Explorer.

Alternatively it is possible to put the tape and disk images in the CHARON VM Home Directory.

Start the "MkDisk" utility by pressing the "Virtual Disk Tool" button in the "Host Information & Utilities" tab of the CHARON Virtual Machine Manager:

The following dialog will appear:

Select "Alpha AXP" in the "Select System" drop-down menu, "SCSI" in the "All Controllers" drop-down menu and "RZ24" (for example) in the "Select Disk Type" drop-down menu.

Press then the "Create Disk Image" button:

The utility will ask you to specify the output file name. Select the "C:\My disks" directory that was created earlier, or create it directly in the dialog, and press the "Save" button:

The "MkDisk" utility will create the requested disk image:

Repeat this sequence for the disks "user-data.vdisk", "application-data.vdisk" and "application-binaries.vdisk". Place them in the same folder.

HINT: Avoid the temptation to name the vdisks according to the disk-model used to create them (example: "RZ56.vdisk"). Such a name tells you absolutely nothing about the purpose of the vdisk. Instead, assign a name to the vdisk file which tells you about its content or purpose, for example "openvms-system", "user-data", "db-data-1", etc.

Installation of Alpha operating system

The next step is to transfer the data from the source Alpha system to CHARON-AXP. The easiest way to do this is via backup over the network but for this operation a bootable network-enabled operating system on a CHARON-AXP disk image or physical disk is needed.

The example configures the CHARON-AXP AlphaServer ES40 system for installation of OpenVMS from a distribution CD-ROM (usually it is "\\.\CdRom0" if the host has only one CD-ROM drive):

# # DEC-KZPBA SCSI controller is mapped to 5 disk containers; one of them (DKA300) - for migration purposes; # another one (DKA400) - for installation of fresh OpenVMS system from distributive
#

load KZPBA PKA scsi_id = 7

set PKA container[0] = "C:\My disks\bootable.vdisk"
set PKA container[100] = "C:\My disks\user-data.vdisk"
set PKA container[200] = "C:\My disks\application-data.vdisk" set PKA container[300] = "C:\My disks\migration.vdisk" set PKA container[400] = "C:\My disks\fresh_openvms.vdisk"

#
# CD-ROM for OpenVMS installation (DQA0)
#

set ide container="\\.\CdRom0"

DKA300 will be the disk where all the source disks will be copied so its size needs to be large enough to store all the disk backup images.

Create an empty disk image for installation of OpenVMS and another one for storing the backups from the source Alpha system as it is shown in the section above.

Run the CHARON VM and boot from the CDROM named "dqa0" ("migration.cfg" is the configuration file we use in this example):

CHARON-AXP/ES40 for Windows x64 (AlphaServer ES40 6/667), Version 4.11.20404
(C) 2009-2020 STROMASYS SA.
All rights reserved.

P00>>>boot dqa0

Install Alpha/VMS including DECnet on "dka400". The DECnet address must belong to the same area as the source Alpha system.

Login to the newly installed OpenVMS system and initialize the disk that will be used to store the backups. Let's assume its prompt is "newvms$ "

newvms$ INIT DKA300: SCRATCH
newvms$ MOUNT/SYSTEM/NOASSIST DKA300: SCRATCH

Making remote backups

Now we are ready to create the disk backups of the source Alpha system on the CHARON VM.

Boot the CHARON VM and make sure that the source Alpha system is available via DECnet.

Login to the source Alpha system. Stop all the batch queues, kick off the users, stop all the applications and close the databases if there are. The commands listed in SYS$MANAGER:SYSHUTDWN.COM may be helpful. The goal is to close as many files as possible. The system disk will have several files opened (pagefile, swapfile, etc.) and this is a normal situation.

The use of the "SHOW DEVICE /FILES" command would be of help to list opened files on a disk.

In this example, the CHARON VM system is node 1.400.

Issue the following commands from the source Alpha. Let's assume its prompt is "source$ ":

source$ BACKUP/IMAGE/IGNORE=INTERLOCK DKA0: 1.400"username password"::DKA300:[000000]DKA0.BCK/SAVE
source$ BACKUP/IMAGE/IGNORE=INTERLOCK DKA100: 1.400"username password"::DKA300:[000000]DKA100.BCK/SAVEsource$ BACKUP/IMAGE/IGNORE=INTERLOCK DKA200: 1.400"username password"::DKA300:[000000]DKA200.BCK/SAVE

When the backup operation will be completed, the disk "DKA300" of the CHARON VM will contain 3 savesets: "DKA0.BCK", "DKA100.BCK" and "DKA200.BCK".

Restore backups to CHARON-AXP disks

The savesets have now to be restored on their corresponding virtual disks. Login to the CHARON VM guest OS and issue this sequence of commands:

newvms$ MOUNT/FOREIGN DKA0:newvms$ BACKUP/IMAGE DKA300:[000000]DKA0.BCK/SAVE DKA0:newvms$ DISMOUNT DKA0:newvms$ MOUNT/FOREIGN DKA100:newvms$ BACKUP/IMAGE DKA300:[000000]DKA100.BCK/SAVE DKA100:newvms$ DISMOUNT DKA100:newvms$ MOUNT/FOREIGN DKA200:newvms$ BACKUP/IMAGE DKA300:[000000]DKA200.BCK/SAVE DKA200:newvms$ DISMOUNT DKA200:

If you are going to have the CHARON VM and the original physical Alpha on the network at the same time, you must change the network identity of one system, usually the CHARON VM.

The easiest way is to boot the CHARON VM on the restored system disk with the network disabled and to configure new addresses then enable the network and reboot.

The NIC can be disabled with a interface="(disabled)" statement in the CHARON VM configuration file.

Alternative ways of data transfer

Some alternative methods of data transfer are also possible. For example:

Connect a SCSI tape drive to the CHARON-AXP host via a PCI card
- Map the tape drive in the CHARON VM configuration file
  a. Restore the source Alpha system backups from tape to disk images via OpenVMS running on the CHARON VM.
  b. Boot from standalone backups and restore the content to the CHARON VM virtual disks
- Dump the source Alpha system backups to tape images using the "mtd" utility and:
  a. Boot from the freshly installed OpenVMS system and restore the tape images to the CHARON VM virtual disks
  b. Boot from the standalone backup and restore the content to the CHARON VM virtual disks
Create a network cluster between the source Alpha system and the CHARON VM (it is possible to use the source system as a boot server); then perform simple backups from one disk to another:
$ BACKUP/IMAGE/IGNORE=INTERLOCK REAL$DKA0: DKA0:

Browser not supported