Anchor | ||||
---|---|---|---|---|
|
...
Option | Description | |||||||
---|---|---|---|---|---|---|---|---|
physical_serial_line | Mapping to host "\\.\COM<n>" physical serial line. | |||||||
virtual_serial_line | Mapping to an IP port of CHARON VM host.
Example:
In the example above, the CHARON VM use uses the IP port "10003" for the VAX/PDP11 console and starts the "Putty" terminal emulator (included in each the CHARON distributiveinstallation kit) with the "OPA0" saved session directing it to connect to the IP port "10003". If the terminal emulator is closed, it is always possible to reopen it with the "Show Console" feature from the CHARON Virtual Machines Manager. |
...
#load physical_serial_line/chserial TTA0 line="\\.\COM1" #load virtual_serial_line/chserial TTA0 port=10000 #load virtual_serial_line/chserial TTA0 port=10000 application="putty.exe -load TTA0" #set quart line[0]=TTA0 #load physical_serial_line/chserial TTA1 line="\\.\COM2" #load virtual_serial_line/chserial TTA1 port=10001 #load virtual_serial_line/chserial TTA1 port=10001 application="putty.exe -load TTA1"
... #load physical_serial_line/chserial OPA0 line="\\.\COM4" #load virtual_serial_line/chserial OPA0 port=10003 load virtual_serial_line/chserial OPA0 port=10003 application="putty.exe -load OPA0"
|
In case of When using the VAX 4000 and MicroVAX 3100 models, it is possible to configure up to 4 independent console lines: OPA0, TTA0, TTA1 and TTA2. The main one is OPA0.
Note there are a number of that additional parameters for the CHARON VM serial lines configuration can be added. Follow this link for details.
Exit on pressing F6 button
It is also recommended to set a hot key to stop the guest VM from the console in addition to the system tray icon(when the console is accessed remotely for example):
set OPA0 stop_on = F6 |
This line provides allows the CHARON VM the ability to exit by VM to be stopped by pressing the "F6" buttonkey.
Disk subsystem
The next step is configuration of the disk subsystem and the mapping it to the system resources can be done using the samples given in the template configuration files.
...
Below is a typical configuration sample for the MSCP disk controller RQDX3:
...
- Mapping to the file representing a physical disk of the VAX/PDP11 system (disk image).
"<file-name>.vdisk"
These files can be created from scratch with "MkDisk" utility. Data and OS disks backups are transferred from the original system via tapes or network and restored into these container files.Mapping may also include the full path (recommended), for example: "C:\My disks\my_boot_disk.vdisk"
Example:
set DUA container[0]="my_bootable_disk.vdisk"
.
Warning Using compressed folders to store virtual disks and tapes is not supported
.
- Mapping to physical disk.
"\\.\PhysicalDrive<N>"
Be careful not to destroy all the information from the disk dedicated to CHARON VM by mistake. These disks must not be formatted by the host OS.
Example:set DUA container[1]="\\.\PhysicalDrive1"
.
- Mapping to physical disk by its WWID.
- "\\.\PhysicalDrive(DevID = <XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX>)"
Be careful not to destroy all the information from the disk dedicated to CHARON VM by mistake. These disks must not be formatted by the host OS.DevID addresses the target physical disk by its WWID (hexadecimal 128-bit identifier assigned to the disk drive by its manufacturer/originator).
Example:
Div class small set DUA container[2]="\\.\PhysicalDrive(DevID= 6008-05F3-0005-2950-BF8E-0B86-A0C7-0001)"
.
- "\\.\PhysicalDrive(DevID = <XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX>)"
Mapping to iSCSI disks.
"\\.\PhysicalDrive(iScsiTarget = <iSCSI target>, LUN = <LUN number>)"
iScsiTarget addresses the disk by its iSCSI target name. LUN specifies LUN on connected iSCSI disk.Example:
Div class small set DUA container[3]="\\.\PhysicalDrive(iScsiTarget= iqn.2008-04:iscsi.charon-target-test1, LUN= 1)"
Div class pagebreak
Mapping to CD-ROM device.
"\\.\CdRom<N>"
Example:
set DUA container[4]="\\.\CdRom0"
.
- Mapping to an ISO file for reading distribution CD-ROM image.
"<file-name>.iso"
Mapping may also include the full path (recommended), for example: "C:\My disks\vms_distributive.iso"
Example:
set DUA container[5]="vms_distributive.iso"
.
- Mapping to Floppy drive.
"\\.\A:"
Example:
set DUA container[6]="\\.\A:"
.
- Mapping to some other type of drive, for example magneto-optical drive.
"\\.\<N>:"
Example:
set DUA container[6]="\\.\H:"
.
Numbers The numbers in the square brackets represent the unit numbers associated with each container of the MSCP controller. For example, the 3rd "set DUA" line of the configuration sample above creates disk "DUA2". 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
Div | ||
---|---|---|
| ||
SCSI controller NCR53C94
The VAX 4000 and MicroVAX 3100 models have an NCR53C94 SCSI controller onboard on board for the support of different types of SCSI devices including disks and tapes. Optionally a second controller can be added.
...
|
In the example above the "pkb_0" virtual SCSI device uses "PKB" controller by specifying a parameter "scsi_bus=pkb"
...
Some MSCP and SCSI controllers support tape devices. CHARON also emulates specific MSCP tape devices such as TQK50 and TUK50.
Follow this link for more details of (T)MSCP controllers configuration.
Warning |
---|
Using compressed folders to store virtual disks and tapes is not supported |
...
Example statements to configure a TQK50 controller are shown below:
|
The first line ("load TQK50 MUA
") loads a tape controller TQK50 with a name of and names it MUA. The following 2 lines demonstrate different ways of mapping to host resources:
Type of mapping | Description |
---|---|
"<file-name>.vtape" | Mapping to the file representing the tape (tape image). These files are created automatically. Mapping may also include a full path (recommended), for example: " C:\My tapes\backup.vtape " |
"\\.\TapeN" | Mapping to a host tape device. |
Numbers in the square brackets represent unit numbers associated with each container of the TQK50 controller. For example, the 2nd "set MUA" line of the configuration sample above creates tape drive the "MUA1" tape drive. The maximum unit number allowed is 9999, significantly more than the original hardware provided
...
The first line loads a UNIBUS BI adapter "DWBUA". Then configure Configure then the "TUK50" tape controller the same way as the TQK50.
...
#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="\\.\COMn" #load virtual_serial_line/chserial TXA0 port=10010 #set TXA line[0]=TXA0 #load physical_serial_line/chserial TXA1 line="\\.\COMn" #load virtual_serial_line/chserial TXA1 port=10011 #set TXA line[1]=TXA1 ... #load DHV11/DHV11 TXB address=... #load DHQ11/DHV11 TXB address=... #load CXY08/DHV11 TXB address=... #load CXA16/DHV11 TXB address=... #load CXB16/DHV11 TXB address=... |
The first 5 lines of the example above demonstrate above are example given for loading serial line controllers of different types. The name of the controller (in this example) will be "TXA".
Div | ||
---|---|---|
| ||
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 "\\.\COM<N>" serial line | |||||||||
virtual_serial_line | Mapping to an IP port of CHARON VM.
Example:
In the example above, the CHARON VM uses the IP port "10011" for the VAX/PDP11 serial line and starts the "Putty" terminal emulator (included in each the CHARON distributiveinstallation kit) with a "TXA0" saved session directing it to connect to the IP port "10011".
|
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 the host serial lines ("TXA<N>").
The number of possible serial lines possible for each controller depends on its type and corresponds to the HP specification on for 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/PDP11 console to determine the addresses. Please refer to specific HP documentation for further information.
The VAX 4000 and MicroVAX3100 models support DHW42-AA, DHW42-BA and DHW42-CA serial lines adapters:
...
Note that additional parameters exist for CHARON VM serial lines configuration , follow can be added. Follow this link for details.
...
In the example above the first line loads DELQA virtual adapter with a name "XQA"; the following 2 lines map it to host network interface having a name "Charon" ("connection" is a key word). Note that the
The mapping is performed in 2 steps:
- A mapping object "packet_port" with a name "XQA0" is loaded and connected to host interface having a name "Charon" , so the CHARON VM will use this interface for its networking
- The loaded DELQA virtual adapter "XQA" is connected to the "packet_port" object "XQA0"
...
Some network adapters available in the CHARON VM are preloaded (for example, the SGEC controller for the MicroVAX 3100 with the predefined name "EZA"), so their configuration is even more simple:
...
After few seconds the chosen interface will be assigned to CHARON:
Follow this link for more details of CHARON VM network controllers configuration.
...
CHARON can be configured to automatically boot an operating system at start up.
The MicroVAX 3100, VAX/PDP11 6310 and VAX/PDP11 4000 models boot automatically if the correct boot flags are set with at the VAX/PDP11 console level:
>>> set halt reboot |
Please check that the TOY, EEPROM and ROM containers (see above) are enabled so console command changes the updated parameters are saved between rebootsupon reboot.
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 to enable auto booting. In this case, some parameters a specific parameter can be defined in the configuration file can be used insteadas a workaround:
set bdr boot=auto |
Div | ||
---|---|---|
| ||
The CHARON-VAX 6000 models have a similar configuration setting:
set xmi boot=auto |
The CHARON-PDP models have the following setting:
...
These configuration lines are typically specified in the template configuration files ( in commented out form). In case of absence please add the corresponding line according to the examples above.
...
Host load balance for SMP systems
The VAX 6620 through VAX6660 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. |
The “affinity” parameter overrides the default and allows explicit specification of which host CPUs will be used by the instance. |
The 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” parameter overrides the default by specifying the number of I/O host CPUs explicitly. |
|