Migrating to a Virtual VAX: An Introduction

Stanley F. Quayle, P.E.President, Quayle Consulting Inc.

Session Goals

• Understand virtualization

• Learn about issues raised by virtualization

• Experience migration with:− Magnetic tape− Disk− DECnet− OpenVMS Cluster− CD-ROM− FTP

Required Experience

• Working knowledge of HP OpenVMS system administration

• If you brought your application, experience in your application

Can It Be Ported?

• Do you have the design documentation?

• Do you have all the source code?− What about DECmigrate (OMSVA)?− VAX SCAN, Dibol, LISP, OPS5, RPG

• Operating system dependency?

• Hardware dependency?

• Target platform− Can your code really be reused?− What about stability?

• Can you validate the result?

Why Virtualize?

• Smaller boxes

• Use modern hardware

• Use corporate SAN

• Reduce power consumption

• Reduce hardware maintenance costs

• “Encapsulate” applications

Virtualization Overview

VAXHardware

CHARN-VAX

Host OS CPU(s)

Application

Layered softwareSystem libraries

Operating System

Application

Layered softwareSystem libraries

Operating System

Host OS

VAX Emulator

Host CPU(s)

VAX Emulator

VAX CPUEmulator

Disk controller

Virtual disk

SCSI VAX disk

Tape image

Tape controller

System businterface

Serial ports

VAXConsole

VTxxxTerminal, etc

EthernetMemory

SCSI VAX tape

Host system diskVAX CPUEmulator

Disk controller

Virtual disk

SCSI VAX disk

Tape image

Tape controller

System businterface

Serial ports

VAXConsole

VAXConsole

VTxxxTerminal, etc

VTTerminal, etc

EthernetMemory

SCSI VAX tape

Host system disk

Virtualize to What?

• SIMH− Open source (“free”)− Support mailing list− Runs on almost any platform

• CHARON-VAX− Commercial product− Support available from VARs− Current platforms: Alpha OpenVMS, Windows− QNX for Q-bus embedded solutions− Future platforms include Linux

OpenVMS Licensing

• HP will transfer existing licenses to CHARON-VAXhttp://h71000.www7.hp.com/openvms/sri-charon-vax-emulator.html

− $ 2,000 total for Intel platform− $ 1,000 total for Alpha platform

• New licenses must be purchased for other virtual solutions

Oracle Licensing

• Oracle will transfer existing Rdb and CODASYL licenses to CHARON-VAX

www.oracle.com/technology/products/rdb/htdocs/rdb7/charon_vax.html− “In most cases, Oracle license and service agreements

are transferred to the same number of CHARON-VAX processors at no charge.”

• New licenses must be purchased for other virtual solutions

MultiNet & TCPware Licensing

• Process Software will transfer existing MultiNet and TCPware licenses to virtual solutions

• Fee depends on emulated system− $ 350 for workgroup-size systems− More for enterprise-size systems

Missing In Action

• Some software vendors no longer exist

• VAX systems do not have a hardware serial number

• Licensing methods:− LMF license PAK− MAC address of Ethernet card− Hardware values of VAX

• CPU• HW_MODEL• SID• XCPU

Software Support

• HP software support (OpenVMS, layered products) is available for CHARON-VAXhttp://h71000.www7.hp.com/openvms/sri-charon-vax-emulator.html

• Oracle Rdb and CODASYL software support available for CHARON-VAX

www.oracle.com/technology/products/rdb/htdocs/rdb7/charon_vax.html

• Other ISV’s support virtual systems less formally

Security Concerns

• How to secure your host− Keep host patch-current− Shut down unnecessary services− Remove unnecessary software− Don’t connect to the network

• How to secure your virtual VAX− All the old VAX tools and tricks still apply− HP OpenVMS Guide to System Security

http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/aa-q2hlg-te.PDF

Let’s Get Started!

• You have the following items:− PC− USB dongle− Install CD− A “bootstrap” VMS system image

• Do not insert the dongle into the USB port yet!

Software Installation

• Insert CD

• Run hldrv32.exe from directory \Hardlock

• Now insert the dongle

• Run \setup.exe

• From Start -> Settings -> Network, install a new protocol on one interface. Select “Have Disk”, and browse to sripacket.inf in directory:C:\Program Files\CHARON-VAX\Drivers\Network\Ndis5

• Disable all other protocols on this adapter

• Disable the protocol on all other adapters

Software Configuration

• Create a directory C:\DISKS

• Copy \DISKS\*.* from the CD to C:\DISKS

• Remove the “read only” property from the files in C:\DISKS

• Open the configuration file (VAX4106.cfg) in Notepad

• Change the network interface name (near the end of the file) to the device which is to be used for the emulated VAX

• Save the changes, and exit Notepad

Virtual VAX Startup

• From the Start button, select CHARON-VAX, then CHARON-VAX Launcher

• Browse to your configuration file

• Run it

• A Hyperterminal window will appear, which is the VAX console

• You now have a VAX on your computer!

• At the >>> prompt, type “B/1 DUA0”

Student Configuration

System DECnet IP

LAB1 1.101 192.168.1.101

LAB2 1.102 192.168.1.102

LAB3 1.103 192.168.1.103

LAB4 1.104 192.168.1.104

LAB5 1.105 192.168.1.105

LAB6 1.106 192.168.1.106

LAB7 1.107 192.168.1.107

LAB8 1.108 192.168.1.108

Configure Your Virtual VAX

• Enter the following at the SYSBOOT> prompt− SET VAXCLUSTER 2− SET VOTES 0− SET EXPECTED_VOTES 1− SET SCSNODE “your assigned node name”− SET SCSSYSTEMID xyz

• Where “xyz” is 1024 + node number (1.101 = 1125)

− CONT

• Once boot is complete, log in as SYSTEM− There’s no password

Configure Networking

• DECnet− @NETCONFIG

• TCP/IP− @UCX$CONFIG

• Start both networks after configuration is done

Pre-Migration Tasks on the VAX• Do an ANALYZE/DISK on each VAX drive, if

possible− Starting with “clean” disks might help prevent problems

• Minimize changes during data movement− Be sure all applications are shut down− Be sure any databases are closed− Shut down queue manager− Make sure users can’t access the system

• SET LOGIN/INTERACTIVE=0 doesn’t stop privileged users− Use standalone backup, if possible

• BACKUP/IGNORE=INTER requires caution

• Locate cluster password, if cluster migration is to be used

Pre-Migration Tasks on the Virtual VAX

• Create empty container files for each disk to be migrated− Some migration methods require an extra “scratch”

container file− Should virtual disks be bigger than originals?

• Update the configuration file− For each container file− If physical tape or disk drives are being added

• Get compatible VMS version for “bootstrap” image− BACKUP changed in V7.2

Pre-Migration Tasks for Infrastructure

• Get new DECnet address and TCP/IP address allocated for virtual VAX

• Make sure VAX and virtual VAX are in same LAN for network migrations

• Secure sufficient downtime window(s) for migration

Our Physical VAX Today

• Workgroup-size VAX− VMS V5.5-2H4− VAXCLUSTER, 1 vote− No SYSTEM password− 1 RZ-29 disk, device name DKA0− 8 mm tape drive, device name MKA300− RRD42 CD drive, device name MKA400

• DECnet address 1.500

• TCP/IP address 192.168.1.500

Tape Migration

• Tape has the following advantages− Tried-and-true technology− Most VAX systems have tape backup− Doesn’t require a network adapter on the VAX− Very familiar system management tasks

• There are disadvantages− Tape is slow− Reliable tapes for older formats (9-track, TK-50, etc.) are

hard to find− Reading the tape on the virtual system requires a SCSI

tape drive

Tape Migration – Procedure

• On the VAX, do backups of all disks− The system disk requires /IMAGE

• Once the backups are done, move the tape drive to the virtual system− The configuration file has to change to use the tape drive

• Do an image restore to new container files on the virtual VAX

Disk Migration

• Disk has the following advantages− Very fast− Doesn’t require a network adapter on the VAX

• There are disadvantages− Only SCSI disks can be migrated this way

• DSSI, CI, MFM disks have no equivalent hardware today

− Handling a disk, especially a very old one, can cause it to fail

• If there’s an external disk array, it could be connected to the virtual VAX permanently− Not highest-performance solution, but migration is

almost zero time and low risk

Disk Migration – Procedure

• Shut down the VAX cleanly

• Connect the disk drives to the virtual system− The configuration file has to change to use the drives

• Do a /IMAGE backup from the physical disks to the container files

DECnet Migration

• DECnet migration has the following advantages− Pretty fast (faster than tape)− Almost every VAX has DECnet installed

• Was required up to V6.x

− BACKUP can write savesets to DECnet nodes

• There are disadvantages− Some VAX systems don’t have a network adapter

DECnet Migration – Procedure

• For each physical disk− BAC/IMG <p>: <vn>”system”::<vd>:[000000]A.BCK/save

• <p> is physical disk name• <vn> is virtual system DECnet address• <vd> is virtual system “scratch” container file

• Then, on virtual system− MOUNT/FOREIGN <vt>:− BAC/IMG <vd>:[000000]A.BCK/save <vt>:

• <vt> is the virtual disk to which to restore

• For multiple disks, these steps can be overlapped if the “<vd>” container file is big enough

Cluster Migration

• Cluster migration has the following advantages− Pretty fast (faster than tape)− All disks to be migrated appear to be local− Migration can be incremental, with mixed physical and

virtual cluster members

• There are disadvantages− Virtual system must be able to join cluster as NI member− The cluster must MSCP-serve all needed disks− Frequently, no one remembers the cluster password

Cluster Migration – Procedure

• On the virtual system, for each physical disk− MOUNT/FOREIGN <vt>:− BACKUP/IMAGE <p>: <vt>:

• <p> is physical disk name• <vt> is the virtual disk to which to restore

CD Migration

• CD has the following advantages− Usually faster than tape− CD drives on virtual VAX are lots faster than RRD-series

VAX drives

• There are disadvantages− Creating ODS-2 CD-ROM’s on VMS was not generally

possible until V7.x− CD’s have a limited size (700 MB max)

• It’s possible to install VMS from scratch using CONDIST disks

CD Migration – Procedure

• If the CD is not in ODS-2 format, follow FTP procedure

• Change virtual VAX configuration file to use PC’s CD drive as a VMS CD drive− Note: Windows must be rebooted if any Windows-format

CD was inserted in drive before starting virtual VAX

• Use COPY or BACKUP to copy files as necessary

FTP Migration

• FTP migration has the following advantages− No use of “DEC proprietary” protocols− Pretty fast− You can FTP files from the host system, which is always

present

• There are disadvantages− Many VAX systems do not have a TCP/IP stack− Some VAX systems don’t have a network adapter− FTP doesn’t preserve VMS file characteristics or boot

blocks

FTP Migration – Procedure

• Configure and start FTP Server on virtual VAX

• Using FTP, transfer files to appropriate locations on virtual VAX

• Be sure to use binary transfers for all but text files

• BACKUP savesets require a fix before restore:− http://www.stanq.com/reset-backup.txt

• Use Info-ZIP with the “-V” option− http://vms.process.com/ftp/vms-freeware/

Post-Migration Tasks

• Before booting the virtual VAX− Make copies of disks as migrated, just in case− Disconnect from network to prevent conflicts with

physical VAX

• Analyze boot messages− Complex cases may need a minimum boot first to sort

out problems− Logical names in SYLOGICALS.COM might be needed

for some hard-coded disk references− Mount commands may be incorrect in startup files

• Re-configure DECnet and TCP/IP

More Post-Migration Tasks

• Regression-test application(s) completely!

• Re-evaluate backup strategy – tape might not be necessary anymore

• Is there a tape archive to be converted?

• License transfers

• Update service contracts

• Shut down VAX and sell on eBay