CHARON-VAX for Linux configuration

Table of Contents


Creation of your own configuration file using a template

All CHARON templates are located in the "/opt/charon/cfg" folder. Copy the appropriate template configuration file(s) to a new directory that you have created specifically for them and give the directory proper permissions. You can name the configuration file as you wish. We recommend <hostname>-<model-name>.cfg. For example: zonker-mv3k6.cfg.

Example:

$ cp /opt/charon/cfg/mv3k6.cfg.template /my_charon_cfg/my_mv3k6.cfg
$ chmod 644 /my_charon_cfg/my_mv3k6.cfg

Please do not edit the original template configuration files since they can be updated or even removed on update/deinstallation of CHARON-VAX

Once the file has been created you can open it in your favorite editing tool and proceed with modifications to reflect the exact features of the system you are going to emulate.

We will review all the parameters step by step issuing some recommendations and guidelines.

Note: the lines preceded by the comment sign "#" inside the configuration files will not be interpreted. You can use this sign to debug your configuration.

VAX model specification

The first configuration statement is the specification of the exact VAX hardware model to emulate.

Example:

set session hw_model = MicroVAX_3600

You must leave this line untouched.

If you create the Charon-VAX configuration file from scratch, it must be the very first uncommented line in the configuration file.


Configuration name

The next configuration statement is the "Configuration name" option.

Example:

#set session configuration_name = MicroVAX_3600

You can optionally uncomment this line to differentiate this CHARON-VAX instance from all others in a multi-instances environment. The configuration name can be any label that is meaningful. It is reported in the log file and is used to set the log file name for rotating log (see further: Rotating log (default)).

Log file parameters

Execution of CHARON-VAX creates one log file or a set of log files reflecting the progress of its start-up and ongoing operation - start and end time of execution, system information, license and configuration details, warnings, reports on problems that may occur, etc. In case of possible problems either with the running CHARON-VAX or the emulated system configuration (such as the absence or malfunction of certain devices), the log file(s) is the primary source to be analyzed for troubleshooting.  If it becomes necessary to contact Stromasys for support, the configuration and log files, plus the license number, will be requested to begin problem resolution.

CHARON-VAX log file example (part1)

20200523:074333:INFO :0:000003A5:hexane.cxx(5952): session: loading built-in configuration "VAX_6610"...
20200523:074333:INFO :0:000003A6:hexane.cxx(5973): session: ... done loading built-in configuration "VAX_6610"
20200523:074333:INFO :0:000003AA:hexane.cxx(6002): session: loading configuration file "vx6k610.cfg"...
20200523:074333:INFO :0:000003AB:hexane.cxx(6026): session: ... done loading configuration file "vx6k610.cfg"
20200523:074333:INFO :0:000003F2:sesmgr.cxx(1419): session: default log file size limit is 4194304 bytes
20200523:074333:INFO :0:0000032B:hexane.cxx(2698): Start request received.
20200523:074334:INFO :0:000003AC:hexane.cxx(1424): session: process affinity is 000000000000000F, system affinity is 000000000000000F
20200523:074334:INFO :0:000003D1:hexane.cxx(1686): session: I/O domain affinity is 0000000000000001, CPU domain affinity is 000000000000000E
20200523:074334:INFO :0:0000024D:licenseman(1823): Checking the available license key "1422726238".
20200523:074334:INFO :0:0000024D:licenseman(1823): Found license key: "1422726238".
20200523:074334:INFO :0:0000024D:licenseman(1823): Checking product section 0.
20200523:074334:INFO :0:0000024D:licenseman(1823): The value "VAX_6610" of the required parameter "P_HW" is not found in the list "AlphaServer_400,AlphaServer_800,AlphaServer_1000,AlphaServer_1000A,AlphaServer_1200,AlphaServer_2000,AlphaServer_2100,AlphaServer_4000,AlphaServer_4100" for the product 0.
20200523:074334:INFO :0:0000024D:licenseman(1823): Checking product section 1.
20200523:074334:INFO :0:0000024D:licenseman(1823): The value "VAX_6610" of the required parameter "P_HW" is not found in the list "AlphaServer_DS10,AlphaServer_DS10L,AlphaServer_DS15,AlphaServer_DS20,AlphaServer_DS25,AlphaServer_ES40,AlphaServer_ES45,AlphaServer_GS80,AlphaServer_GS160,AlphaServer_GS320" for the product 1.
20200523:074334:INFO :0:0000024D:licenseman(1823): Checking product section 2.
20200523:074334:INFO :0:0000024D:licenseman(1823): The value "VAX_6610" of the required parameter "P_HW" is not found in the list "PDP1193,PDP1194" for the product 2.
20200523:074334:INFO :0:0000024D:licenseman(1823): Checking product section 3.
20200523:074334:INFO :0:0000024D:licenseman(1823): HASP clock: 23-May-2019 08:47:05.
20200523:074334:INFO :0:0000024D:licenseman(1823): Host clock: 23-May-2019 07:43:34.
20200523:074334:INFO :0:0000024D:licenseman(1823): License number: "003.msc.test.center.kirill".
20200523:074334:INFO :0:0000024D:licenseman(1823): Product License number: "p.vax".
20200523:074334:INFO :0:0000024D:licenseman(1823): CHARON product code: "CHVAX-4110xx-WI-LI".
20200523:074334:INFO :0:0000024D:licenseman(1823): Unlimited license.
20200523:074334:INFO :0:0000024D:licenseman(1823): Feature 1 check interval 1 hour(s).
20200523:074334:INFO :0:0000024D:licenseman(1823): Concurrency info:
20200523:074334:INFO :0:0000024D:licenseman(1823): There are 7 instances allowed.
20200523:074334:INFO :0:0000024D:hexane.cxx(2848): STROMASYS SA, (C) 2009-2020
20200523:074334:INFO :0:00000408:hexane.cxx(2892): CHARON-VAX (VAX 6000 Model 610), V 4.12 B 21009, May 14 2020 / 003.msc.test.center.kirill / 1422726238
20200523:074334:INFO :0:00000336:hexane.cxx(2924): The end user of this software has agreed to STROMASYS' Terms and Conditions for Software License and Limited Warranty, as described at: /pub/doc/30-17-033.pdf
20200523:074334:INFO :0:00000097:hexane.cxx(2999): OS Environment: Red Hat Enterprise Linux Server release 7.4 (Maipo), Linux 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 13 10:46:25 EDT 2017 x86_64.
20200523:074334:INFO :0:00000098:hexane.cxx(3004): Host CPU: GenuineIntel, Family 6, Model 42, Stepping 1, Intel Xeon E312xx (Sandy Bridge), 1 Sockets, 1 Cores per Socket, 4 Threads per Core, at ~2593 MHz, 4 cpu's available

CHARON-VAX log file example (part2)

20200523:074334:INFO :0:00000099:hexane.cxx(3009): Host Memory: 3840Mb
20200523:074334:INFO :0:0000041F:hexane.cxx(3224): Configuration dump::

. session:
. . configuration_name = "VAX_6610"
. . log_method = "overwrite"
. . hw_model = "VAX_6610"
. . log_mode = "shared"
. . log_locale = "english"
. XMI:
. . clock_period = "20000"
. . boot = "manual"
. RAM:
. . size = "512"
. eeprom:
. . container = "charon.rom"
. TOY:
. . container = "charon.dat"
. OPA0:
. . trace = "disabled"
. . stop_on = "F6"
. . tx_flush_delay = "0"
. PUA:
. . container[0] = "/home/charon/Charon/test/performancecomparison-66x0.vdisk"
. . xmi_node_id = "11"
. EXA:
. . adapter_mode = "auto"
. . interface = "EXA0"
. . rx_fifo_delay_on_overload = "false"
. . extended_command_ring = "false"
. . xmi_node_id = "13"
. EXA0:
. . interface = "eth1"
. . disabled_mode = "10BaseT-HD"
. . port_show_driver_statistics = "false"
. . port_enable_mac_addr_change = "true"
. . port_snd_sock_buf_size_kb = "0"
20200523:074336:WARN :1:00000431:lnxpackpor(1006): (95) Operation not supported: EXA0: ioctl("eth1", SIOCETHTOOL, GSET)
20200523:074336:INFO :0:00000001: tpool.cxx(1374): CPU: The ACE option is omitted; enable ACE as license default.
20200523:074337:INFO :0:00000133: tpool.cxx(1606): Advanced CPU Emulation (ACE) enabled.
20200523:074337:INFO :0:00000400:ethdev.cxx( 388): EXA: RX FIFO size is 512KB.
20200523:074338:INFO :0:0000032C:hexane.cxx(2740): "VAX_6610" started.
20200523:074345:INFO :0:0000014F:lnxpackpor(1652): EXA0: Carrier loss detected.
20200523:074539:INFO :0:000003D7:hexane.cxx(5548): All virtual CPUs of "VAX_6610" have been stopped by now.
20200523:074539:INFO :0:0000032D:hexane.cxx(2784): "VAX 6000 Model 610" stop request received.
20200523:074539:INFO :0:0000014C:lnxpackpor( 433): EXA0: Stopping network interface ... please wait.
20200523:074539:INFO :0:0000024D:licenseman(1823): Licensing component received stop request.
20200523:074539:INFO :0:0000032E:hexane.cxx(2811): Stopped.
20200523:074539:INFO :0:0000014C:lnxpackpor( 433): EXA0: Stopping network interface ... please wait.

The next group of parameters defines the name of the CHARON-VAX log file and how CHARON-VAX will use it:

set session log_method = append
#set session log_method = overwrite
#set session log = "MicroVAX_3600.log"


Rotating log (default)

By default CHARON-VAX utilizes a so called "rotating log" mechanism. This means that a new default log file is created each time CHARON starts and can switch to another log file if the size of the log file exceeds 64Kb (this behavior can be changed with the "set session log_file_size" and "set session log_rotation_period" parameters; see more details in the "General Settings" chapter of this guide). 

This mode is turned on if all the log parameters above are disabled (commented out) or the "session_log" parameter is pointing to an existing directory rather than to a file. If a directory is specified, the log files will be created in that directory.

The names of the rotating log files are composed as follows:

configuration_name-YYYY-MM-DD-hh-mm-ss-xxxxxxxxx.log

If the "Configuration name" parameter described before is omitted (commented out), the log name has the following format instead:

hw_model-YYYY-MM-DD-hh-mm-ss-xxxxxxxxx.log

Note that "xxxxxxxxx" is an increasing decimal number starting from "000000000". During a session (the time between start and stop of the emulator), when the log file is rotated, this number will be incremented by 1.

Only an existing directory can be used as a value of the "log" parameter.

Single log

Alternatively it is possible to use a single log file: uncomment the "set session log" line and specify the desired CHARON-VAX log file name. Optionally, a path can be added to the log file name. If the path is not specified, the log file is created in the directory from where the guest (emulated machine) is started.

The log file can be extended ("log_method = append") or overwritten ("log_method = overwrite") by CHARON-VAX.

Below is a specification of a CHARON-VAX log file located in the "/my_logs" directory which will be appended each time CHARON-VAX starts:

set session log_method = append
set session log = "/my_logs/my_vax.log"

TOY, ROM and EEPROM containers

The next objects to be configured are TOY, ROM and EEPROM containers. Their presence depends on the VAX model. It is always recommended to enable them. If a container file of the given name does not exist, CHARON-VAX will create it. Specific paths can be added to the file name specification.

TOY means "Time of Year"; its container records time, date and some console parameters while CHARON-VAX is not running. To enable the TOY, uncomment the following line:

set toy container="/my_charon_dir/charon.dat"

The ROM container stores an intermediate state of the Flash ROM and some console parameters. It is highly recommended to define its location:

set rom container="/my_charon_dir/vx4k106.rom"

EEPROM stores the NVRAM content. It is highly recommended to define its location:

set eeprom container="/my_charon_dir/charon.rom"


Emulated memory (RAM) size

The next parameter defines the amount of host memory the chosen CHARON-VAX model reserves for the emulation.

Example:

set ram size=64

The amount of RAM is specified in MB. It cannot exceed or be lower than certain values specific for each VAX model. It is very important to keep the listed predefined increment between possible memory values.

The following table lists all the parameters per model:

Hardware Model

RAM size (in MB)


Min

Max

Default

Increment

MicroVAX_II

1

16

16

1, 8, 16

MicroVAX_3600

16

64

16

16

MicroVAX_3900

16

64

16

16

VAXserver_3600

16

64

16

16

VAXserver_3900

16

64

16

16

VAXserver_3600_128

32

128

32

32

VAXserver_3900_128

32

128

32

32

MicroVAX_3100_Model_96

16

128

16

16

VAXstation_4000_Model_90

16

128

16

16

VAX_4000_Model_106

16

128

16

16

VAX_6000_Model_310

32

512

32

32

VAXserver_3600_512

32

512

32

32

VAXserver_3900_512

32

512

32

32

MicroVAX_3100_Model_98

16

512

16

16

VAX_4000_Model_108

16

512

16

16

VAX_4000_Model_700

64

512

64

64

VAX_4000_Model_705

64

512

64

64

VAX_6610

128

3584

128

128

VAX_6620

128

3584

128

128

VAX_6630

128

3584

128

128

VAX_6640

128

3584

128

128

VAX_6650

128

3584

128

128

VAX_6660

128

3584

128

128

It is possible to leave the RAM line commented out. In this case the model's default RAM amount is used.


Console

Mapping to system resources

The next step is the specification of the VAX console (OPA0) serial line.

Example:

#load physical_serial_line OPA0 line="/dev/ttyN"
#load virtual_serial_line OPA0 port=10003

load operator_console OPA0

The goal of this configuration step is to tell CHARON-VAX what host device to use as the virtual system console. The following options are available:

OptionDescription
physical_serial_line

Mapping to host serial line, both physical and virtual. Use the following mapping for different types of host serial lines:

  • /dev/tty<N> for virtual serial lines
  • /dev/ttyS<N> for onboard serial lines
  • /dev/ttyUSB<N> for modem or usb serial lines adapters

Please note: If the emulator will be configured to use a physical serial port ("/dev/ttyNN"), it must either be run as the root user or the non-privileged user must be a member of the dialout group.

virtual_serial_line

Mapping to an IP port of CHARON-VAX host.
Using this mapping it is possible to connect to the CHARON-VAX console and disconnect from it at any time.

operator_consoleMapping to the current TTY console

The default setting is "operator_console".

Note that the VAX 4000 and MicroVAX 3100 models have a 4-line QUART adapter onboard so their configuration for the console line looks a bit different:

#load physical_serial_line/chserial TTA0 line="/dev/tty<N>"
#load virtual_serial_line/chserial TTA0 port=10000
#set quart line[0]=TTA0 
... 

#load physical_serial_line/chserial TTA2 line="/dev/tty<N>"
#load virtual_serial_line/chserial TTA2 port=10002
#set quart line[2]=TTA2

#load physical_serial_line OPA0 line="/dev/tty<N>"
#load virtual_serial_line OPA0 port=10003

load operator_console OPA0
set quart line[3]=OPA0

IF VAX 4000 and MicroVAX 3100 models are used, it is possible to configure up to 4 independent console lines: OPA0, TT0, TT1 and TT2. The main one is OPA0.

(warning) Note there are a number of additional parameters for CHARON-VAX serial line configuration. Follow this link for details.


Exit on pressing F6 key

A hot key can be defined to stop the execution of the CHARON-VAX virtual machine:

set OPA0 stop_on = F6

It is strongly recommended to uncomment this line to provide CHARON-VAX the ability to exit by pressing the "F6" key.

Disk subsystem

The next step is the configuration of the disk subsystem and mapping it to the system resources using the samples given in the template configuration files.

CHARON-VAX supports MSCP, DSSI, CI and SCSI disk controllers. The examples below are for MSCP and SCSI controllers only. DSSI controllers are discussed in details in the following section and CI controllers in this section.

MSCP disk controllers (RQDX3, KDB50, KDM70)

Below is a typical configuration sample for MSCP disk controller RQDX3:

load RQDX3 DUA

#set DUA container[0]="<file-name>.vdisk"
#set DUA container[1]="/dev/sdN"
#set DUA container[2]="/dev/srN"
#set DUA container[3]="<file-name>.iso"

#load RQDX3 DUB address=...
#load RQDX3 DUC address=...


The first line ("load RQDX3 DUA") loads disk controller RQDX3 with name DUA, followed by 4 lines showing different ways of mapping to the host resources:

Type of mappingDescription
"<file-name>.vdisk"

Mapping to files representing physical disks of the VAX system (disk images). 
These files can be created from scratch with "mkdskcmd" utility. Data and OS disk backups are transferred from the original system via tapes or network and restored into these container files. 
Mapping may also include the full path, for example: "/my_disks/my_boot_disk.vdisk" 

"/dev/disk/by-id/<ID>"
 -or-
"/dev/disk/by-uuid/<UUID>"

Mapping to physical disks. "L" is letter here. Be careful not to destroy all the information from the disk dedicated to Charon-VAX by mistake! These disks can not be formatted by the host OS.

(info) It is also possible to a particular partition of a disk. In this case the syntax is the following: "/dev/disk/by-<thing>/<ID/UUID><PART>" where <thing> is "id" or "uuid", <ID/UUID> is the corresponding entry in the directory and <PART> is the number of partition to be used. 

Beware: Since "/dev/sd<L>" addressing is not persistent, so it is strongly recommended to use "/dev/disk/by-id/wwn-*" or "/dev/disk/by-uuid/<UUID>" syntax instead to refer the disk by its ID or WWID - especially in the enviroments utilizing FC and SAN storages (see below)

"/dev/dm-<N>"
"/dev/mapper/mpath<N>"
"/dev/mapper/disk<N>"

Mapping to multipath disk.

(warning) Beware: When passing a Linux storage device via the emulator to the guest operating-system, you must take care to avoid writing to the device at the Linux level – doing this will destroy all data on a disk 

These disks must not be formatted by the host OS.

"/dev/disk/by-*"

Mapping to physical disk.

  • by-id (addressing by the disk ID, for example "/dev/disk/by-id/ata-ST1000DM003-9YN162_S1D01QJ4")
  • by-label (addressing by the disk label, for example "/dev/disk/by-label/MyStorage")
  • by-uuid (addressing by the disk UUID, for example "/dev/disk/by-uuid/0e808a2f-cdd3-4944-a245-f729ffd73882")

(warning) Be careful not to destroy all the information from the disk dedicated to CHARON-VAX by mistake.

These disks must not be formatted by the host OS.

"/dev/sr<N>"Mapping to CD-ROMs. There are some variants of this mapping: "/dev/cdrom<N>" or "/dev/cdrom"
"<file-name>.iso"Mapping to an ISO file for reading distribution CD-ROM images.

The numbers in the square brackets represent unit numbers associated with each container of the MSCP controller. For example, the line of the configuration sample above, referring container #2, creates the "DUA2" disk. The maximum unit number allowed is 9999, significantly more than the original hardware provided.

It is possible to load several RQDX3 controllers DUB, DUC, etc. (see lines 6-7, above) by configuring specific addresses for them on the Qbus. Use the "CONFIGURE" utility available on the VAX console to determine the addresses. Please refer to specific HP documentation for further information.

Please also refer to the HP documentation for information on placement of additional KDM70 controllers on an XMI bus (VAX 6000 models) and additional KDB50 controllers on a BI bus (VAX 6310).

Note that the KDM70 controller is capable of mapping to files representing tapes (tape images) and physical tape devices:

set PUA container[600] = "<file-name>.vtape"
set PUA container[601] = "/dev/sg<N>" 

Follow this link for details of (T)MSCP controllers configuration.


SCSI controller NCR53C94

The VAX 4000 and MicroVAX 3100 have an NCR53C94 SCSI controller onboard for support of different types of SCSI devices including disks and tapes. Optionally a second controller can be added.

Below is a typical configuration template for a preloaded "PKA" NCR53C94 SCSI controller:

# Mapping to disk image
load virtual_scsi_disk pka_0 scsi_bus=pka scsi_id=0

set pka_0 container="<file-name>.vdisk"

# Mapping to physical disk
load virtual_scsi_disk pka_1 scsi_bus=pka scsi_id=1

set pka_1 container="/dev/sd<L>"

# Mapping to some SCSI device connected to the host
load physical_scsi_device pka_2 scsi_bus=pka scsi_id=2

set pka_2 container="/dev/sg<N>"

# Mapping to host CD-ROM or DVD-ROM
load virtual_scsi_cdrom pka_3 scsi_bus = pka scsi_id = 3
set pka_3 container = "/dev/cdrom<N>"
#set pka_3 container = "/dev/sr<N>"

# Mapping to *.ISO image
load virtual_scsi_cdrom pka_4 scsi_bus=pka scsi_id=4

set pka_4 container="<file-name>.iso"

# Mapping to tape drive
load physical_scsi_device pka_5 scsi_bus=pka scsi_id=5

set pka_5 container="/dev/sg<N>"

# Mapping to tape image
load virtual_scsi_tape pka_6 scsi_bus=pka scsi_id=6

set pka_6 container="<file-name>.vtape"

# Include this line to get access to "PKB" adapter
include kzdda.cfg

# Mapping to host floppy drive
load virtual_scsi_disk pkb_6 scsi_bus=pkb scsi_id=6
set pkb_6 container="/dev/fd<N>" 


Note that NCR53C94 SCSI controller mapping to system resources is done via specific auxiliary objects:

Mapping ObjectDescription
virtual_scsi_disk

Mapping to a file representing VAX disk (disk image) on the host physical disk:

  • "<file-name>.vdisk"
    These files can be created from scratch with "mkdskcmd" utility. Data and OS disk backups are transferred from the original system via tapes or network and restored into these container files. Mapping may also include the full path, for example: "/my_disks/my_boot_disk.vdisk"
  • "/dev/dm-<N>", "/dev/mapper/mpath<N>", "/dev/mapper/disk<N>" - for multipath disks. N is 0,1,2...
  • "/dev/disk/by-id/..." - addressing by the disk ID, for example "/dev/disk/by-id/ata-ST1000DM003-9YN162_S1D01QJ4"
  • "/dev/disk/by-label/..." - addressing by the disk label, for example "/dev/disk/by-label/MyStorage"
  • "/dev/disk/by-uuid/..." - addressing by the disk UUID, for example "/dev/disk/by-uuid/0e808a2f-cdd3-4944-a245-f729ffd73882"
  • "/dev/sd<L>" - name of a physical disk. "L" is letter here. (DO NOT USE SUCH DEVICES THEY ARE NOT PERSISTENT)
  • "/dev/df<N>" - name of host CD-ROM drive. N is 0,1,2... This parameter can be omitted.

Beware: When passing a Linux storage device via the emulator to the guest operating-system, you must take care to avoid writing to the device at the Linux level – doing this will destroy all data on a disk.

Beware: Since "/dev/sd<L>" addressing is not persistent, so it is strongly recommended to use "/dev/disk/by-id/wwn-*" or "/dev/disk/by-uuid/<UUID>" syntax instead to refer the disk by its ID or WWID - especially in the enviroments utilizing FC and SAN storage.

(info) It is also possible to a particular partition of a disk. In this case the syntax is the following: "/dev/disk/by-<thing>/<ID/UUID><PART>" where <thing> is "id" or "uuid", <ID/UUID> is the corresponding entry in the directory and <PART> is the number of partition to be used.  

physical_scsi_device

Mapping to a host SCSI device:

  • "/dev/sg<N>" - name of the SCSI device for direct mapping, for example, a SCSI disk or tape reader.
virtual_scsi_cdrom

Mapping to a host CD-ROM (not only SCSI) or to ISO image:

  • "/dev/sr<N>", "/dev/cdrom", "/dev/cdrom<N>" - name of host CD-ROM drive
  • "<file-name>.iso" - name of ISO image. It may contain the full path, for example: "/my_disks/vms_distributive.iso"
virtual_scsi_tapeMapping to a file representing tape (tape image). It may contain a path, for example: "/my_tapes/backup.vtape"


Let's look at the syntax of the mapping objects. All of them have several important parameters:

Mapping objects parametersDescription
scsi_busThe name of the NCR53C94 SCSI controller. A typical value for the first and only preloaded NCR53C94 SCSI controller is "PKA" 
scsi_idSCSI address of this particular mapped device. Note that the preloaded NCR53C94 SCSI controller claims address "7"; addresses 0-6 are vacant and useable.
The resulting names of virtual SCSI devices as they are seen in VAX/VMS are made up of the VMS name of the SCSI controller and the device address. For PKA, the device names in VMS will be DKA0, DKA1 etc
containerA keyword for specification of which host device is mapped to a particular virtual SCSI device. It can be disk or tape image, physical disk etc

It is possible to configure another NCR53C94 SCSI controller "PKB" by uncommenting the "include kzdda.cfg" line:

include kzdda.cfg

load virtual_scsi_disk pkb_0 scsi_bus=pkb scsi_id=0
set pkb_0 container="<file-name>.vdisk"
...

In the example above "pkb_0" virtual SCSI device uses "PKB" controller by specifying a parameter "scsi_bus=pkb"

Note that versions of VAX/VMS older than 5.5-2H4 do not support the optional SCSI controller and might fail to boot if it is loaded.

Follow this link for details of NCR53C94 SCSI controller controllers configuration.

Tape subsystem

Some MSCP and SCSI controllers support tape devices, however CHARON-VAX also emulates specific MSCP tape devices such as TQK50 and TUK50.

Follow this link for more details of (T)MSCP controllers configuration.

TQK50 controller

Example statements to configure TQK50 are shown below:

#load TQK50 MUA

#set MUA container[0]="<file-name>.vtape"
#set MUA container[1]="/dev/sg<N>"

#load TQK50 MUB address=...
#load TQK50 MUC address=...

The first line ("load TQK50 MUA") loads tape controller TQK50 with a name of MUA. The following 2 lines demonstrate different ways of mapping to host resources:

Type of mappingDescription
"<file-name>.vtape"

Mapping to files representing tapes (tape images).
Such files can be created automatically or transferred from physical tapes with "mtd" utility
Mapping may also include a full path, for example: "/my_tapes/backup.vtape"

"/dev/sg<N>"Mapping to host tape devices.

Numbers in the square brackets represent unit numbers associated with each container of the TQK50 controller. For example, line 3 of the configuration sample above creates tape drive "MUA1". The maximum unit number allowed is 9999, significantly more than the original hardware provided

It is possible to load several TQK50 controllers (see the lines 4-5) by configuring specific addresses for them on the Qbus. Use the "CONFIGURE" utility available on the VAX console to determine the addresses. Please refer to specific HP documentation for further information.

TUK50 controller

TUK50 is a UNIBUS controller used by the VAX 6310:

load DWBUA UBA vax_bi_node_id = 14

load TUK50 MUA

#set MUA container[0] = "<file-name>.vtape"
#set MUA container[0] = "/dev/sg<N>"

The first line loads a UNIBUS BI adapter "DWBUA". Configure then the "TUK50" tape controller the same way as the TQK50.


Serial Lines

CHARON-VAX supports the following serial lines controllers: CXA16, CXB16, CXY08, DHQ11, DHV11, DZV11, DZQ11, DL11, DLV11, DZ11, DHW42-AA, DHW42-BA and DHW42-CA.

All of them are configured according using the following template:

#load DHV11/DHV11 TXA
load DHQ11/DHV11 TXA
#load CXY08/DHV11 TXA
#load CXA16/DHV11 TXA
#load CXB16/DHV11 TXA

load physical_serial_line/chserial TXA0 line="/dev/tty0"
#load virtual_serial_line/chserial TXA0 port=10010
set TXA line[0]=TXA0

#load physical_serial_line/chserial TXA1 line="/dev/tty<N>"
#load virtual_serial_line/chserial TXA1 port=10011
#set TXA line[1]=TXA1

...

#load DHV11 TXB address=...
#load DHQ11 TXB address=...
#load CXY08 TXB address=...
#load CXA16 TXB address=...
#load CXB16 TXB address=...

The first 5 lines of the example above demonstrate loading serial line controllers of different types. The name of the controller in this example will be "TXA".

Once the controller is loaded it can be mapped to system resources (lines 6-11). The following options are available:

OptionDescription
physical_serial_line

Mapping to host serial line, both physical and virtual. Use the following mapping for different types of host serial lines:

  • /dev/tty<N> for virtual serial lines
  • /dev/ttyS<N> for onboard serial lines
  • /dev/ttyUSB<N> for modem or usb serial lines adapters
virtual_serial_line

Mapping to an IP port of CHARON-VAX.
This mapping makes it possible to connect to and disconnect from the CHARON-VAX console at any time.

The example above loads a DHQ11 serial line controller with one "TXA0" line mapped to the host virtual serial line "/dev/tty0".

Look at the line "set TXA line[0]=TXA0" in the example: this one and the following lines of similar syntax map the loaded virtual controller ("TXA") to instances of host serial lines ("TXA<N>").

The number of serial lines possible for each controller depends on its type and corresponds to the HP specification of a given controller.

It is possible to load several CXA16, CXB16, CXY08, DHQ11, DHV11, DZV11, DZQ11, DL11, DLV11 and DZ11 controllers (see the lines 12-16) by configuring specific addresses for them on the Qbus. Use the "CONFIGURE" utility available on the VAX console to determine the addresses. Please refer to specific HP documentation for further information.


VAX 4000 and MicroVAX3100 support DHW42-AA, DHW42-BA and DHW42-CA serial lines adapters:

#load DHW42AA/DHV11 TXA
#load DHW42BA/DHV11 TXA
#load DHW42CA/DHV11 TXA

#load physical_serial_line/chserial TXA0 line="/dev/tty<N>"
#load virtual_serial_line/chserial TXA0 port=10010
#set TXA line[0]=TXA0

Configuring these adapters is the same as above, except it is possible to load one and only one instance of DHW42-AA, DHW42-BA or DHW42-CA.

Note that additional parameters exist for CHARON-VAX serial lines configuration, follow this link for details.

Networking

CHARON-VAX supports DEQNA, DESQA, DELQA, DEUNA, DELUA, DEMNA, DEBNI and PMADAA virtual network adapters.

All of them are configured in a similar way:

load DELQA/DEQNA XQA

load packet_port/chnetwrk XQA0 interface="eth1"
set XQA interface=XQA0

#load DELQA XQB address=...
#load DELQA XQC address=...

In the example above the first line loads a DELQA virtual adapter named "XQA". The following 2 lines map it to the host network interface "eth1".

Note that the mapping is performed in 2 steps:

  1. A mapping object "packet_port" named "XQA0" is loaded and connected to the host interface "eth1" so CHARON-VAX will use this interface for its networking
  2. The loaded DELQA virtual adapter "XQA" is connected to the "packet_port" object "XQA0"

It is possible to load several DEQNA, DESQA, DELQA, DEUNA and DELUA controllers (see the lines 4-5) by configuring specific addresses for them on the Qbus. Use the "CONFIGURE" utility available on the VAX console to determine the addresses. Please refer to the HP specific documentation for further information.

Some network adapters available in CHARON-VAX are preloaded (for example, the SGEC controller for the MicroVAX 3100 with the predefined name "EZA"), so their configuration is even more simple:

load packet_port/chnetwrk EZA0 interface="eth1"
set EZA interface=EZA0

CHARON supports VLAN adapters. If used, proceed with their installation and configuration according to the network adapter vendor User's Guide and then use the resulting VLAN interface the same way as the regular network interface. 

Follow this link for more details of CHARON-VAX network controllers configuration.


Auto boot

CHARON-VAX can be configured to automatically boot an operating system at start up.

The MicroVAX 3100,  VAX 6310 and VAX 4000 models boot automatically if the correct boot flags are set at the VAX console level:

>>>set halt reboot

Please check that the TOY, EEPROM and ROM containers (see above) are enabled so the console changes are saved upon reboots.

The ROM of certain VAX models (MicroVAX II, MicroVAX 3600, MicroVAX 3900, VAXserver 3600 and VAXserver 3900) does not allow the SRM console to accept the above command to enable auto booting. As a workaround, a specific setting can be defined in  the configuration file:

set bdr boot=auto

The CHARON-VAX 6000 models have a similar configuration setting:

set xmi boot=auto

Host load balance for SMP systems

The VAX 6620 through VAX 6660 models emulate 2-6 CPUs respectively. In this situation, loading of the host system can be tuned with the following configuration file settings:

SettingDescription
affinity

This setting binds the running instance of the emulator CPUs to particular host CPUs. This should be used for soft partitioning host CPU resources or for isolating multiple CHARON instances on the same host from each other.

By default the emulator instance allocates as many host CPUs as possible. 

“Affinity” overrides the default and allows explicit specification of which host CPUs will be used by the instance. Affinity does not reserve the CPU for exclusive use.

Example:

set session affinity = "0, 2, 4, 6"

n_of_io_cpus

Reserves host CPUs (of those specified by “affinity” parameter, if any) for use by the emulator for I/O handling.

By default the emulator instance reserves one third of available host CPUs for I/O processing (round down, at least one).

The “n_of_io_cpus” overrides the default by specifying the number of I/O host CPUs explicitly.

Example:

set session n_of_io_cpus = 2



© Stromasys, 1999-2024  - All the information is provided on the best effort basis, and might be changed anytime without notice. Information provided does not mean Stromasys commitment to any features described.

Kirill Nikolaev (Unlicensed)
May 15, 2019

Yes I will discuss it with Vadim

Bruno Miretti (Deactivated)
May 20, 2019

Same here, this is the line that is missing in the example, not in Charon