| Anchor | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
...
| 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 |
...
Note there are a number of additional parameters for CHARON-VAX serial line configuration. Follow this link for details.Status
Exit on pressing F6
...
key
A hot key can be defined to stop the execution of the CHARON-VAX virtual machine:
|
It is strongly recommended to uncomment this line to provide CHARON-VAX the ability to exit by pressing the "F6" buttonkey.
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)
...
| 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.
| ||
| "/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.
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. |
Numbers The numbers in the square brackets represent unit numbers associated with each container of the MSCP controller. For example, the line 3 of the configuration sample above, referring container #2, creates disk 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).
...
|
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 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.
...
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:
...
The first line loads a UNIBUS BI adapter "DWBUA". Then configure Configure then the "TUK50" tape controller the same way as the TQK50.
...
All of them are configured according to using the following template:
|
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:
| 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. |
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 : 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 on 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.
...
In the example above the first line loads a DELQA virtual adapter with a name named "XQA"; the . The following 2 lines map it to the host network interface "eth1".
Note that the mapping is performed in 2 steps:
- A mapping object "packet_port" with a name named "XQA0" is loaded and connected to the host interface "eth1" , so CHARON-VAX will use this interface for its networking
- 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 HP documentation for further information.
...
| Info |
|---|
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.
...
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 with at the VAX console level:
|
Please check that the TOY, EEPROM and ROM containers (see above) are enabled so the console command changes are saved between upon reboots.
The ROM of certain VAXes VAX models (MicroVAX II, MicroVAX 3600, MicroVAX 3900, VAXserver 3600 and VAXserver 3900) does not allow the SRM console to accept the commands above command to enable auto booting. In this case, use a configuration file setting insteadAs a workaround, a specific setting can be defined in the configuration file:
|
The CHARON-VAX 6000 models have a similar configuration setting:
...
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:
| 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. |
|
...