Anchor | ||||
---|---|---|---|---|
|
Include Page | ||||
---|---|---|---|---|
|
...
Here is an example of a field test CHARON-VAX log file:
|
The next group of parameters defines the name of CHARON-VAX log file and how CHARON-VAX will use it:
|
The next group of parameters defines the name of CHARON-VAX log file and how CHARON-VAX will use it:
|
...
By default CHARON-VAX utilizes a so called "rotating log". This means that a new default log file is always created each time CHARON starts and can switch to another log file in some situations. This if the size of the log file exceeds 64Kb (This behavior can be changed with "set session log_file_size" and "set session log_rotation_period" commands; see more details in "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 a directory rather than to a file. If a directory is specified, the log files will be created in that directory.
...
Div | ||
---|---|---|
| ||
|
Emulated memory (RAM) size
The next parameter defines the amount of host memory the chosen CHARON-VAX model reserves for the emulation:
...
:
|
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 shows all the parameters:
...
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
...
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_128512 | 32 | 128512 | 32 | 32 |
MicroVAX_3100_Model_9698 | 16 | 128512 | 16 | 16 |
VAXstationVAX_4000_Model_90108 | 16 | 128512 | 16 | 16 |
VAX_4000_Model_106700 | 1664 | 128512 | 166416 | 64 |
VAX_60004000_Model_310705 | 3264 | 512 | 326432 | 64 |
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 VAX console (OPA0) serial line:
#load physical_serial_line OPA0 line="/dev/ttyNVAX_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.
Div | ||
---|---|---|
| ||
|
Console
Mapping to system resources
The next step is the specification of VAX console (OPA0) serial line:
|
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:
Option | Description |
---|---|
physical_serial_line | Mapping to host serial line, both physical and virtual. Use the following mapping for different types of host serial lines:
|
virtual_serial_line | Mapping to an IP port of CHARON-VAX host. |
operator_console | Mapping 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:
Option | Description |
---|---|
|
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:
...
In case of VAX 4000 and MicroVAX 3100 models it is possible to configure up to 4 independent console lines: OPA0, TT0, TT1 and TT2. The main one is OPA0.
Note there are a number of additional parameters for CHARON-VAX serial line configuration. Follow this link for details.
Exit on pressing F6 button
The next parameter in the template configuration file relevant to the console is the specification of a hot key to trigger an exit from CHARON-VAX:
|
It is strongly recommended to uncomment this line to provide CHARON-VAX the ability to exit by pressing the "F6" button.
Disk subsystem
The next step is configuration of the disk subsystem and mapping it to 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, CI controllers - in this section.
MSCP disk controllers (RQDX3, KDB50, KDM70)
Below is a typical configuration sample for MSCP disk controller RQDX3:
|
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 mapping | Description |
---|---|
"<file-name>.vdisk" | Mapping to files representing physical disks of the VAX system (disk images). |
"/dev/sd<L>" |
Mapping to host serial line, both physical and virtual. Use the following mapping for different types of host serial lines:
/dev/ttyS<N> - onboard serial lines /dev/ttyUSB<N> - modem or usb serial lines adapters |
virtual_serial_line | Mapping to an IP port of CHARON-VAX host. |
operator_console | Mapping 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
Mapping to physical disks. "L" is letter here. Be |
In case of VAX 4000 and MicroVAX 3100 models it is possible to configure up to 4 independent console lines: OPA0, TT0, TT1 and TT2. The main one is OPA0.
Note there are a number of additional parameters for CHARON-VAX serial line configuration. Follow this link for details.
Exit on pressing F6 button
The next parameter in the template configuration file relevant to the console is the specification of a hot key to trigger an exit from CHARON-VAX:
|
It is strongly recommended to uncomment this line to provide CHARON-VAX the ability to exit by pressing the "F6" button.
Disk subsystem
The next step is configuration of the disk subsystem and mapping it to 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, CI controllers - in this section.
MSCP disk controllers (RQDX3, KDB50, KDM70)
Below is a typical configuration sample for MSCP disk controller RQDX3:
|
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 mapping | Description | |||
---|---|---|---|---|
"<file-name>.vdisk" | Mapping to files representing physical disks of the VAX system (disk images). | |||
"/dev/sd<L>" | 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. It is also possible to use not a whole disk, but previously created partitions on it. In this case the syntax is the following: "/dev/sd<L><N>" where N is the number of partition to be used.
| |||
"/dev/dm-<N>" "/dev/mapper/mpath<N>" "/dev/mapper/disk<N>" | Mapping to multipath disk. 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/disk/by-*" | Mapping to physical disk.
Be careful not to destroy all the information from the disk dedicated to CHARON-VAX by mistake | ! . These disks | can must not be formatted by the host | OS. It is also possible to use not a whole disk, but previously created partitions on it. In this case the syntax is the following: "/dev/sd<L><N>" where N is the number of partition to be used. 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. |
...
Follow this link for details of (T)MSCP controllers configuration.
Back to Table of Contents
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.
...
|
Note that NCR53C94 SCSI controller mapping to system resources is done via specific auxiliary objects:
Mapping Object | Description |
---|---|
virtual_scsi_disk | Mapping to a file representing VAX disk (disk image) on the host physical disk: 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"
|
Note that NCR53C94 SCSI controller mapping to system resources is done via specific auxiliary objects:
Mapping Object | Description | ||
---|---|---|---|
virtual_scsi_disk | Mapping to a file representing VAX disk (disk image) on the host physical disk:
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.
It is also possible to use not a whole disk, but previously created partitions on it. In this case the syntax is the following: "/dev/sd<L><N>" where N is the number of partition to be used. | ||
physical_scsi_device | Mapping to a host SCSI device:
| ||
virtual_scsi_cdrom | Mapping to a host CD-ROM (not only SCSI) or to ISO image:
| ||
virtual_scsi_tape | Mapping 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:
...
Host load balance for SMP systems
VAX 6620 through VAX6660 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:
Setting | Description | Example | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
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. |
| ||||||||
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. |
|
...