|
||
Before starting to define the configuration of the Alpha emulator it is a good strategy to make sure you have the environment prepared and the required data available. We advise the following steps:
The configuration file determines the components of the emulated Alpha and their mapping onto the host system hardware. Parameters and values are to be entered manually, so please be careful to follow the instructions and keep the comment lines intact so you will be able to trace back typo's in your configuration parameters. The configuration file is structured per device type to enhance the logic of the definition:
Configuration variables are defined when their values are set, no special
declaration is required. NOTE: Configuration variables are
case sensitive. For example, “model” can’t be changed to “Model”. CHARON-AXP in its base configuration standard offers support up to 4 GB
virtual Alpha memory. This is expandable by purchasing 4 GB Alpha memory
support options. Please note that the virtual Alpha does not support more
memory than the original Alpha computer model (e.g. an AlphaServer 4000 with
12 GB memory does not exist and therefore cannot be virtualized) The standard value is 512, so also in case you use higher memory sizes you
must change this parameter memory xxx Where xxx is the amount of alpha memory you want to emulate in MB. Define emulated Alpha model Depending on the Alpha you want to emulate (because of license requirements) you need to specify the model that needs to be emulated. Which models can be emulated can be found in the release notes. model xxx Where xxx is the model you want to emulate, for example: AS200, AS1000,
AS4000, AS2100 etc. Define emulated marketing model number (smm) and hardware model The system that is emulated is defined by several parameters, like model and memory In addition to these parameters the following optional parameters can override the default marketing model number and hardware model of the system system.smm=xxxx By default each system will have a correct smm value but in some special cases this needs to be adjusted. The number is in some cases used for 3rd party product licensing where the license locks itself to the Mac address and/or the marketing model number of the system. system.hw_name="xxxx" By default the system will have a correct hardware model name, but in some special cases this needs to be adjusted. The name is in some cases used for 3rd party product licensing where the license is locked to this hardware model. Define number of emulated CPU's Depending on the model emulated, the number of emulated CPU's can be
defined. (maximum of 4 CPU's) system.cpus=x This section defines the name and values of the OPA0 console. This console can be a VT-terminal connected through a COM-port or Ethernet socket. Three different instruction variants exist: OPA0.type="..." defines which console type is connected. Value telnet, socket or device Example 1, using a VT terminal connected to COM1 Example 2, using telnet over Ethernet port 20000 Example 3, using the standard Windows Hyperterm terminal emulator
listening on port 123 *) Hyperterm or any other VT-terminal emulator may have to be installed on your system first. Look into the Tips&tricks section for configuration tips regarding the various terminal emulators. CHARON-AXP supports physical and logical disks (including .iso CD-ROM
image ). Physical disks can be either identified by their Windows disk name
(e.g. \\.\Physicaldrive3) or by their SCSI address (e.g. \\.\scsi2: 0 2 1).
Logical disks are container files within a Windows directory that can be
treated as regular Alpha disks. They are visible within Windows, but their
content is only accessible for the Alpha Emulator. Currently only SCSI disks are emulated which are attached to emulated SCSI
adapters. You can define up to 10 emulated SCSI adapters (PKA, PKB, PKC, PK..) to attach your emulated SCSI peripherals to, by issuing the following statement: load x PK Where x is the number of SCSI adapters you want to emulate. The Emulator automatically generates PKA up to PK.., depending to the number of adapters you select. After this you can attach the various disks to the adapters as follows: load DKAxxx Where xxx is the disk-id that you obtain from your VMS operating system (e.g. DKA0, DKA103, DKA234, DKB100) . Now the actual location of the emulated disk has to be assigned to each device by using the command: DKAxxx.image="<location>" The location can be a file in a Windows directory (e.g. c:\Alpha\disk1.vdisk) or the Windows disk-id (e.g. \\.\Physicaldrive1) that can be obtained from the Windows device manager. DKAxxx.readonly=on Readonly (on,off) will make the disk(image) write protected (default=off) DKAxxx.removable=on Removable (on,off) will make the disk(image) removable, the file or device
will be unlocked in Windows when dismounted in VMS (default=off) DKAxxx.shared=on Shared (on,off) will open the disk(image) without locking the disk(image).
(default=off) Remember that when the option shared is used for clustering, disk read_cache and disk write_cache needs to be disabled too, to prevent disk corruption! DKAxxx.read_cache=on Read_cache (on,off) will enable/disable the host read caching (default=safe value with respect to shared, which is opposite value of shared) Remember that when the option shared is used for clustering, disk read_cache and disk write_cache needs to be disabled too, to prevent disk corruption! DKAxxx.write_cache=off Write_cache (on,off) will enable/disable the host write caching (default=safe value with respect to shared, which is opposite value of shared) Remember that when the option shared is used for clustering, disk read_cache and disk write_cache needs to be disabled too, to prevent disk corruption! DKAxxx.mapped=on Mapped (on,off) will map the disk image to the memory of the host system and use the memory-mapped IO to perform the disk access (default=off). This increases IO performance, but take into account that after a power failure not all data from memory is written back to the disk and data might get lost. (It is advised to use this option with read_cache and write_cache enabled) Disk geometry settings In some situations especially when using shadowing or clustering the disk
geometry must be the same on multiple disks, to make sure they are the same
you can use the parameters below. DKAxxx.bps=512 bps defines the number of bytes per sector on the disk DKAxxx.tpc=16 tpc defines the number of tracks per cylinder on the disk. DKAxxx.spt=99 spt defines the number of sectors per track on the disk. DKAxxx.ncyl=2595 ncyl defines the number of cylinders on the disk. DKAxxx.size=2104565760 Size defines the total size of the disk. DKAxxx.vendor="<diskvendorname>" Vendor allows to set the name of the disk vendor. DKAxxx.product="<diskproducttype>" Product allows to set the name of the diskproducttype. DKAxxx.revision="<diskrevision>" Revision allows to set the revision number of the disk.
It is also possible to connect a physical SCSI disk. In that case the prefix changes to GKAxxx (G stands for generic, since it is unknown whether a disk, tape or other SCSI device is attached). The operating system will recognize the correct device type and apply the correct prefix for use in the operating system. GKAxxx.image="<scsi-address>" Example: load 2 PK load DKA0 Note: In this case it is not possible to load for example a DKCxxx disk since you have only loaded 2 SCSI adapters. Tape configuration Virtual tapes: load MKA0 To load and unload a virtual tape a utility for VMS called "emulator_tapeutil" is provided on the "drivers.vdisk" see special options. this utility works similar to a tape library and allows to create/load/unload/delete a virtual tape image from within your VMS using DCL commands. Example: $ TAPE_CREATE "C:\Tapes\tape0.vtape" (This will create a empty
tape tape0.vtape) MKAxxx.limit=1073741824 Limit (in bytes) will limit the maximum size of a tape image and will report end of tape. LOAD MKA400 MKAxxx.autoload=on Autoload (on,off) will enable/disable auto loading of the tape container
file (default=off) Physical tapes: If windows has a driver loaded for the tape drive and the tape is enabled in the device manager use: Load MKA400 MKA400.image=\\.\Tape0 or Load GKA400 GKA400.image="\\.\Tape0" However this does not work for all types of tape drives, so if above fails, disable the device in the device manager and use direct SCSI addressing: Load GKA401 GKA401.image="\\.\Scsiw: x y z" Were w is the For example GKA401.image="\\.\Scsi2: 0 2 2" The Alpha Emulator supports loadable Ethernet adapters to be activated with the following command: load x EW <model> Which will automatically generate the
Ethernet adapters EWA0 - EWD0, depending on the value of x (1 - 4) The emulated network card will usually be mapped to a windows network adapter. Please make sure that the selected Ethernet adapters have the Alpha Emulator NDIS driver activated (network properties under Windows). This will be automatically activated by the installation procedure. The Ethernet configuration parameter
Where y is the id of the Ethernet adapter
you want to configure (A - ...), EWy0.iface="memory" If <adapter name> is set to "memory" then no physical network adapter is used, but a shared memory location on the host. This way multiple instances on the same host can create a local network to communicate to each other in a very fast way. NOTE in case DECnet is used it is important to understand that a DECnet address change forces a change of the MAC-address of your Ethernet adapter. On an Alpha computer OpenVMS takes care of this immediately, but in the case of the Alpha Emulator this task is performed by the operating system of the host platform. This creates a difference between the Alpha operating system expectations and the actual situation. Therefore this may require a reboot of the emulator after a DECnet address change has been applied. If you do not reboot unpredictable problems can occur. If you need to change the initial value of the MAC Address then use the following line: EWA0.macaddr="<mac address>" <mac address> needs to be in the form : "XX-XX-XX-XX-XX-XX" Example: load 2 EW DE435 EWA0.macaddr="AA-00-04-00-FF-FF" EWB0.iface="RealTEK RTL8139" Serial line adapter configuration The Alpha emulator supports up to 8 serial line ports emulating a PBXDA serial lines adapter. The command load x TX opens 8 logical serial line ports that need to by specified per port with a .type a .port and .command descriptor. Up to 7 TX devices are supported. NOTE: Depending on the operating system you are running on the Alpha Emulator you may be required to install the appropriate drivers in that operating system to make get access to the serial ports. The serial line command syntax is: TXA.linex.type="<value>"
Value can be telnet, socket
or device Example: load 1 TX TXA.line0.type="telnet" Starting the system This is the last command in the configuration file which powers up the
virtual Alpha you defined here.
|
||
|