vtServer® vtAlpha/vtVAX Bare Metal Reference Manual
Version 3.2.0
© 2018 AVTware® June 2018 vtServer® Reference Manual v3.2.0
Table of Contents 1. General Description and Terminology ...... 5 2. Product Installation, Version Upgrade and Standard Boot ...... 6 2.1. Upgrade/repair ...... 6 2.2. Install vtServer ...... 6 2.3. Install vtLicense ...... 7 2.4. Pre-defined Installation ...... 7 2.5. Snapshot management ...... 7 2.6. Boot from the first hard drive ...... 8 2.7. Version Updates ...... 8 2.8. Booting vtServer ...... 8 3. vtServer Host Management ...... 9 3.1. Top-level Menu ...... 9 3.2. vtControl Menu ...... 10 3.2.1. Console Access ...... 10 3.2.2. Management Console ...... 10 3.2.3. Start/Stop Emulator ...... 10 3.3. Configuration ...... 10 3.3.1. Account ...... 11 3.3.2. Alerts ...... 11 3.3.3. Console ...... 12 3.3.4. Network ...... 12 3.3.5. Hostname ...... 13 3.3.6. Update ...... 13 3.3.7. Installation of optional kits...... 14 3.3.8. License ...... 14 3.3.9. Datetime ...... 14 3.3.10. Keyboard ...... 15 3.3.11. Services ...... 16 3.3.12. vtCloud ...... 18 3.3.13. Snapshots ...... 22 3.3.14. Sysinfo ...... 23 3.4. Shutdown/Reboot ...... 23 3.5. Graphics ...... 24 3.5.1. X Server Start ...... 24 3.5.2. Display ...... 24 3.5.3. Autostart ...... 24 3.5.4. Security ...... 24 3.5.5. Advanced ...... 25 3.6. Support ...... 25 4. vtMonitor/vtLicense Management Tool ...... 26 4.1. Login...... 27 4.2. Configuration Management ...... 27 5. Configuring Virtual Alpha Systems ...... 29 5.1. Buttons Description ...... 29 5.2. Comment Box ...... 29 5.3. vtAlpha Configuration Name ...... 29 5.4. Hardware Model ...... 29 5.5. Advanced Options ...... 30 5.6. QBB ...... 30 5.7. Virtual CPUs ...... 31 Page 2
June 2018 vtServer® Reference Manual v3.2.0
5.8. CPU Details ...... 31 5.9. Memory ...... 32 5.10. OPA0 / COM2 ...... 32 5.11. PCI Bus ...... 33 5.12. PCI Slot ...... 34 5.13. Ethernet Adapter ...... 35 5.14. Serial Lines Adapter ...... 35 5.15. SCSI Adapter ...... 37 5.16. Fibre Channel Adapter ...... 38 5.17. Virtual Device Adapter ...... 40 5.18. Storage Devices ...... 42 6. Configuring vtVAX ...... 44 6.1. Configuration Name ...... 45 6.2. Environment: License Group ...... 45 6.3. Environment: Temporary License ...... 45 6.4. CPU: VAX Model ...... 45 6.5. CPU: Memory ...... 46 6.6. CPU: NVRAM file ...... 46 6.7. CPU: Auto Boot ...... 46 6.8. CPU: EcoMode ...... 46 6.9. CPU: Instruction Caching ...... 46 6.10. CPU: Instruction Delay ...... 47 6.11. CPU: Instruction Delay TMO ...... 47 6.12. Console: OPA0 ...... 47 6.13. Console: Break Key ...... 47 6.14. Console: Console Password ...... 47 6.15. TTA Lines: TTAx ...... 48 6.16. vtVAX Storage ...... 48 6.17. Physical Devices ...... 48 6.18. Logical Devices ...... 48 6.19. Storage Configuration Parameters ...... 49 6.20. Specifying Device Location ...... 49 6.21. MSCP Storage ...... 50 6.22. SCSI Storage ...... 50 6.23. DSSI Storage ...... 50 6.24. Network ...... 51 6.25. Serial Lines ...... 53 6.26. Miscellaneous: Printer File ...... 53 6.27. VCB02 Stub ...... 53 7. Storage Management ...... 54 7.1. Host Storage Tab ...... 54 7.2. Storage Overview ...... 55 7.3. Mounting/Dismounting Disks ...... 55 7.4. Logical Device Management ...... 56 7.5. Fibre Channel Storage (SAN) ...... 57 7.6. iSCSI ...... 58 7.7. NFS ...... 59 7.8. SMB...... 60 8. Toolbox ...... 61 8.1. Host ...... 61 8.2. Network ...... 63 8.3. User Accounts ...... 67 Page 3
June 2018 vtServer® Reference Manual v3.2.0
8.4. License Mgt ...... 67 8.5. Backup ...... 68 8.6. Support ...... 69 9. Firewall (vtLicense only) ...... 70 10. Special Operations ...... 71 10.1. vtAlpha/vtVAX License in a Network...... 71 10.1.1. Functional Description ...... 71 10.1.2. Network License Installation Instructions ...... 72 10.2. X-Windows Terminal Access on vtAlpha/vtVAX Host (workstation)...... 73 10.2.1. General ...... 73 10.2.2. Single Network Interface Systems...... 73 10.2.3. DECwindows Setup on VMS ...... 74 10.2.4. DECwindows Setup on Tru64 [vtAlpha only] ...... 75 10.3. Improving I/O Performance ...... 75 10.4. Transferring Files to/from the vtServer Host ...... 76 10.4.1. Windows Client ...... 76 10.4.2. Linux Client ...... 76 10.5. TapeMGR [for managing logical tapes] ...... 76 10.6. Eco App [vtAlpha only] ...... 79 10.6.1. Installing the Eco App for OpenVMS ...... 79 10.6.2. Activating the Eco App for Tru64 v5 ...... 80 10.7. vtSID Utility [vtVAX only] ...... 80 10.8. Installing vtServer in a Hypervisor ...... 83 10.8.1. Symmetric Multiprocessing (SMP)...... 83 10.9. Security Settings ...... 84 10.10. Installing Serial Line Drivers in OpenVMS ...... 84 10.11. Boot from Fibre Channel (vtAlpha only) ...... 88 10.12. MOP boot ...... 90 10.13. Clock_mode in SRM console ...... 90 10.14. Installing Tru64 on a Fibre Channel Disk (vtAlpha only) ...... 90 10.15. Pre-defined vtAlpha/vtVAX Installation (Installation Auto-Pilot) ...... 91 10.15.1. Example parameters.conf ...... 97 10.15.2. Example presetup.sh script ...... 98 10.15.3. Example postsetup.sh script ...... 100 10.15.4. Example template.conf ...... 100
Page 4
June 2018 vtServer® Reference Manual v3.2.0
1. General Description and Terminology vtAlpha and vtVAX for Bare Metal are Alpha and VAX virtualization products that execute on 64-bit X86 architecture computer systems: either on a physical host or in a Virtual Machine environment. Both products utilize Bare Metal technology: they install directly on the physical or virtual host without a separately installed operating system. All references to vtVAX in this document refer to the vtVAX for Bare Metal product; vtVAX for Windows is documented separately. The product set consists of the following elements: vtAlpha, Alpha virtualization supporting OpenVMS and Tru64; vtVAX, VAX virtualization supporting VMS/OpenVMS; vtServer, the host control environment that supports the Alpha and VAX emulations; vtMonitor, the web browser-based system management tool; vtLicense, network license server. vtServer is the Virtual Machine Manager which controls the host hardware and allows multiple vtVAX and vtAlpha instances to run in parallel on a single host. The system manager may create any number of vtVAX and vtAlpha configurations. The content of the license key determines the maximum number of instances that may execute concurrently. The primary management tool is vtMonitor, which is a web browser-based GUI that is used to define and manage vtAlpha and vtVAX configurations. vtMonitor also manages the host storage elements (local storage, network storage, and SAN) as well as the network infrastructure. vtMonitor may run from any location with HTTP connectivity to the host(s) running vtServer. vtServer also allows a user to manage the vtServer system from a local console in case there is no network available for the vtMonitor connection. vtLicense is a dedicated license server that allows distributing vtAlpha and vtVAX licenses in the company network, enabling the setup of disaster tolerant installations. vtLicense is a dedicated unit provided by AVT or Vere with a management interface that is very similar to vtMonitor. Unless specifically noted, the information provided in this manual applies to both vtAlpha and vtVAX for Bare Metal. The remainder of this manual is organized as follows: Chapter 2 describes the process for installing and updating the software. Chapter 3 provides a detailed description of the vtServer console management interface. Chapter 4 describes the vtMonitor/vtLicense user interface. Chapter 5 describes the configuration and management of virtual Alpha systems and their associated storage and network resources. Chapter 6 describes the configuration and management of virtual VAX systems and their associated storage and network resources. Chapter 7 describes the host storage management. Chapter 8 describes the Toolbox, a tabs used to manage the vtServer host environment. Chapter 9 describes the firewall settings; this is only available in vtLicense. Chapter 10 describes uncategorized features.
Page 5
June 2018 vtServer® Reference Manual v3.2.0
2. Product Installation, Version Upgrade and Standard Boot The vtAlpha, vtVAX for Bare Metal, vtServer, and vtMonitor software is provided as a single installation kit on a USB installation device or an ISO image file. Software updates and patches are distributed as TGZ format files that are uploaded to the host, or they may be installed from the distribution media as an update rather than a full re-installation of the software. Booting from the installation media offers the following options:
2.1. Upgrade/repair This option will look for update versions on the install media and apply them in sequence. This upgrade method is especially useful when previous upgrades are skipped. The process will sort out which ones need to be applied. It also allows reparation of a damaged installation. 2.2. Install vtServer Installs vtServer, vtAlpha, vtVAX and vtMonitor on this system and prepares it to act has a host computer for your virtual Alpha and VAX environment. Anything that was on the disk will be overwritten by this installation. The installation process requires the following user input: 1) Read and accept the license terms for vtAlpha and vtVAX. 2) Select the appropriate keyboard language, and time zone. 3) Select the target disk for the installation. NOTE: installation is supported only when the target is a physical device (e.g., /dev/sdb), not a partition (e.g., /dev/sdb1). When installing to a device with existing partitions, all the partitions will be destroyed. 4) Acknowledge that the selected disk will be overwritten. 5) Enter and confirm the password for the root account. This account is created during installation. The root account is required to access the vtServer host menu structure and perform certain system management functions. This account cannot be removed. 6) Set the size of the storage you want to use for the vtServer software. The default value of 0 will use the entire device for the software. A non-zero value will result in a partition of the specified size being created for the software; the remaining storage on the device will be allocated to a second partition with the label data that can be mounted temporarily or permanently in the vtMonitor Storage tab. The minimum partition size for the vtServer software is 8 GB. We recommend allocating at least 40 GB for the vtServer software to provide adequate room for dynamic files such as logs as well as future software growth.
Page 6
June 2018 vtServer® Reference Manual v3.2.0
7) Upon completion of the installation, reboot the host system from the installation target device to start vtServer. 2.3. Install vtLicense Installs vtLicense and prepares it to act has a vtLicense to distribute vtAlpha and vtVAX licenses in the company network. Anything that was on the disk will be overwritten by this installation. The installation process requires the following user input: 1) Read and accept the license terms for vtAlpha and vtVAX. 2) Select the appropriate keyboard language and time zone. 3) Select the target disk for the installation. NOTE: installation is supported only when the target is a physical device (e.g., /dev/sdb), not a partition (e.g., /dev/sdb1). When installing to a device with existing partitions, all the partitions will be destroyed. 4) Acknowledge that the selected disk will be overwritten. 5) Enter and confirm the password for the root account. This account is created during installation. The root account is required to access the vtLicense host menu structure and perform certain system management functions. This account cannot be removed. 6) Upon completion of the installation, reboot the host system from the installation target device to start vtLicense. 2.4. Pre-defined Installation The pre-defined installation function, also known as unattended installation, allows users with multiple similar vtServer installations to automate the installation and configuration of these host systems using custom installation templates. The templates can perform operations such as importing prepared virtual VAX and Alpha configurations and disk images, and setting network and other configuration parameters. Please see section 10.13 for detailed instructions on how to prepare the pre-defined installation templates. 2.5. Snapshot management With the snapshot option it is possible to preserve the state of the system at a particular point in time. When needed, a snapshot earlier made can be used to bring the system back to the state when the snapshot is made. Snapshots are only available on disks formatted with the btrfs filesystem. The snapshot utility will scan all available disks to see whether at least one of them is a btrfs disk. When no btrfs disk is available an error message will be shown.
VtServer installations before 3.2.0 are usually installed on an ext4 disk. To enable snapshots, vtServer must be re- installed and the new installation must be on a btrfs file system disk. This will remove the current installation, including all the configurations.
Page 7
June 2018 vtServer® Reference Manual v3.2.0
Before upgrading, a snapshot will be made automatically (if possible). By using the snapshot made before the upgrade it is always possible to restore the system state to the state before the upgrade. Snapshots can be made manually when needed. It is advisable to make a snapshot before complex and/or large changes are made to vtServer or its configuration. 2.6. Boot from the first hard drive In case the host BIOS/UEFI is configured to boot from USB/DVD prior to hard disk, this option overrides that and boots from the first hard disk it can find. 2.7. Version Updates As with the initial installation, updates to vtServer, vtAlpha, vtVAX, vtLicense and vtMonitor are bundled in a single package. There are several ways to update the software: 1) Boot from the Installation DVD for the new version and select the Upgrade/Repair option from the menu; 2) Select the Update option from the vtServer Configuration menu on the host system console; 3) Select the Product Update option from the Host tab in the vtMonitor Toolbox. When using methods (2) or (3), a small TGZ file containing the incremental update may be copied to the /update directory on the host using FTP prior to beginning the update, or it may be installed from the installation DVD or a USB storage device. When the update is performed from vtMonitor it may be uploaded from the user’s PC at the time the update process is initiated. Incremental updates will apply only to software at the release level immediately prior to that of the update; if there is a gap, all previous updates must be applied manually in sequence. The last portion of the full release number corresponds to the suffix of the update file for that release (e.g., update46.tgz is used to update from version 3.0.0-45 to 3.0.1-46). 2.8. Booting vtServer vtAlpha and vtVAX virtual machines can be configured to be started manually or to auto-start when vtServer is rebooted. The vtServer boot menu contains an option to reboot with auto-start disabled if it is desired to override the auto-start behavior for this boot only.
Page 8
June 2018 vtServer® Reference Manual v3.2.0
3. vtServer Host Management After installing the vtServer software and rebooting the host system, a vtServer logon prompt will be displayed on the host console. The user may login using the root password that was specified during the installation process. Most vtServer functions may be configured using the vtServer menus on the host console, as described in this chapter, or using vtMonitor, as described in Chapter 4. The vtServer menu system is similar to that used for applications such as PC BIOS configuration menus. Most menu screens consist of a display area with one or more options that can be selected and a control area with one or more buttons to initiate an action (usually ‘OK’ to select the entry, and ‘Cancel’ to return to the previous menu). The up and down arrows are used to move between the menu items; the Tab key or the left and right arrows are used to move between the buttons. Enter initiates the selected button. Menus that require text input function a bit differently: The Tab key must be used to move the selection between text input boxes and the control buttons. Once a control button is highlighted, the left and right arrow keys (or Tab) may be used to move between buttons. Enter initiates the selected function. Screen view: The top line of this screen shows the version of vtServer and the IP host name and-address (when assigned). Additional information will be displayed when connected to this console from a different IP address or when a remote support session is active. A warning message will be displayed when a valid license key is not detected. The vtServer menus are described in detail below. 3.1. Top-level Menu The top level vtServer menu contains the following options, which are described in detail below: - Display and change the status of the virtual Alpha or VAX instances defined on this host. - Change vtServer host system parameters. - Shutdown or reboot the host system. - Start the graphics environment on the host. - Access vtMonitor from the host console. - Log out of vtServer (does not affect running emulation instances).
Page 9
June 2018 vtServer® Reference Manual v3.2.0
3.2. vtControl Menu The vtControl menu window (left, below) displays the status of all defined virtual Alpha and VAX configurations; selecting a configuration displays the configuration control menu (right, below) which is used to start or stop the emulator, connect to the emulator console port, or enable/disable the auto-start status.
3.2.1. Console Access Connect to one of the console interfaces on the selected virtual Alpha or VAX: console (OPA0), or console2 (COM2 – Alpha only).
3.2.2. Management Console To be used under guidance of your virtual Alpha and VAX support contact.
3.2.3. Start/Stop Emulator This menu is used to change the state of the selected configuration; the option displayed depends on the current state of the instance. If the guest operating system is running, it will not be stopped before the emulator is shut down. 3.3. Configuration The Host Configuration menu contains the following options: - Add/remove/alter user accounts used for vtServer/vtMonitor system management - Set email address to receive system alerts - Modify the welcome text displayed on the vtMonitor login screen - Change the host network settings - Change the host name - Apply a version and/or license key update - Define a remote vtAlpha/vtVAX license server - Change the host date and time settings - Change the host keyboard settings - Change the services settings. - Change/setup the cloud settings. - Perform snapshot tasks. - Show system information.
Page 10
June 2018 vtServer® Reference Manual v3.2.0
3.3.1. Account The Account menu is used to add or delete system manager accounts and change account passwords. These accounts are used to login to the vtServer management interface of vtMonitor: all accounts have full access to perform all system management functions.
To enhance security, password lifetime may be enabled on an account-by-account basis. Password lifetime is disabled by default. There are two password expiration parameters: Maximum Days specifies the age at which a password must be changed: when the user logs on to vtServer or vtMonitor after this period has expired they will be forced to change the password before continuing. The Minimum Days parameter prevents a user from changing a password before the specified period has elapsed. The default value of 0 indicates there is no minimum password lifetime.
3.3.2. Alerts The vtServer alert notification feature will send email messages to defined users when any of the following conditions occur: - vtAlpha/vtVAX license is not available when an emulator is active - vtAlpha/vtVAX license expired (warnings continue for 16 hours before shutdown) - Disaster Recovery License has less than 24 hours of run-time remaining - High host CPU utilization - High host memory utilization - OpenVMS Bug check detected - vtServer system partition/disk almost full Additional alert conditions will be added in the future. User suggestions are welcome. Now, all alert notifications are sent to all defined recipients. The Alert Management menu contains the following items: email adds emails addresses to the alert notification list. sender select the account the alert emails will be sent from (default: root) smtp is used to specify the name or IP address of your SMTP email server (e.g., mail.company.com). When no SMTP server is defined, vtServer will attempt to identify one using DNS MX records. test generates a test notification message.
Page 11
June 2018 vtServer® Reference Manual v3.2.0
3.3.3. Console The Console menu is used to edit and format a welcome message that is displayed on the vtMonitor login screen. Basic editing options are available (color, bold, underline, etc.). Details are available by selecting Help from this menu. The root account password must be entered before changes can be made.
3.3.4. Network The Network Configuration menu provides access to the network and management interface configuration options. Some network connectivity troubleshooting tools are available. The configuration functions may also be performed using vtMonitor after the management network connectivity has been provided.
The IP menu item has 3 options: - Setup the individual interface settings - Set the Default Gateway for this host, which may be overridden per adapter - Define the DNS servers for this host system
Interface displays a list of physical and logical network interfaces present on the host system. Selecting an interface displays the configuration menu, including line state information. The IP settings of the selected interface can be configured for a static address or DHCP. See Chapter 8.2 for additional information regarding configuration of the network interfaces. gateway is used to define the default gateway for this host and interface- specific gateways, if desired. dns is used to configure settings for up to 3 DNS servers.
network switch is used to create and configure virtual network switches. See section 8.2 of this manual for detailed documentation on vtServer virtual network switches.
Page 12
June 2018 vtServer® Reference Manual v3.2.0
management is used to add or remove network management ports, which are used to share vtMonitor management traffic and regular virtual Alpha or VAX network traffic on a single interface. vlan is used to assign virtual LAN (VLAN) IDs to host Ethernet adapters. VLAN definitions are meaningful only if the existing network infrastructure is configured to support them. bond manages the virtual bond devices from this menu (see section 8.2 for details). tools provide access to the ping and traceroute network utility programs, which are used to troubleshoot network connectivity problems. order is used to manually change the sequence of the Ethernet adapters.
3.3.5. Hostname This menu is used to change the host name and domain of this vtServer host. If no name or domain is specified, vtServer.avt will be used by default. When maintaining multiple vtServer hosts in a network, you should assign unique names. NOTE: The DNS domain is used to identify an SMTP server using DNS MX records when system alerts are enabled, and no SMTP server is specified.
3.3.6. Update The update menu is used to apply vtAlpha/vtVAX/vtServer/vtMonitor software updates from one of several sources: The installation DVD; A USB storage device or a CDROM/DVD containing the update kit; The /update directory on the vtServer host.
For details on the update process, see Chapter 2 of this manual. usbdvd applies updates from the vtServer installation DVD (or ISO-image) or update incremental update files located on a USB stick, CD, or DVD. local applies updates previously copied to the /update directory on the host system. To copy files to the host, the FTP or SMB servers must be enabled. Optional allows for manual selection of specific updates. This option is used to apply “patch” kits provided with product releases.
Page 13
June 2018 vtServer® Reference Manual v3.2.0
3.3.7. Installation of optional kits. Optional kits are located on the vtServer installation media and can be installed in two ways: 1. From the vtServer host menu: “configuration” --> “update” ---> “optional” --> “CD/DVD”
Select the removable storage that contains the kit
Select the appropriate kit from the list to install, or select remove graphics to delete a previously installed graphics kit.
2. Using the “Product Update” button from the “Toolbox” menu in vtMonitor.
3.3.8. License The vtAlpha and vtVAX licensing mechanism utilizes license specifications stored on a hardware license container. By default, each vtServer host looks for the license container on a local port. Show displays the content of the license key(s) accessible to this host. The vtServer host can be configured to check for license containers on remote host systems or dedicated vtLicense servers. The use of remote license servers increases configuration flexibility and allows for disaster-tolerant configurations. The license menu has two options: remote is used to define one or more remote license servers that vtServer will poll for the required vtAlpha or vtVAX license. enable is used to enable the remote server capability on this host so that it may function as a remote license server. Refer to Chapter 10.1 for more information regarding the remote license capability.
3.3.9. Datetime Change the date and time on the host system. Date and time can be set to manual update, or to use NTP to automate the date and time setting. The time zone can be set to get the correct date and time when using NTP.
Page 14
June 2018 vtServer® Reference Manual v3.2.0
3.3.10. Keyboard Select the desired keyboard layout. The current keyboard setting is used as default.
Page 15
June 2018 vtServer® Reference Manual v3.2.0
3.3.11. Services vtServer supports a lot of services which can be enabled (or disabled) using the services menu. Some services need extra configuration settings.
By default, services are disabled. Each may be started using the corresponding option in the host menu (or vtMonitor). The services may be started for the current instance of vtServer only, or they may be enabled each time vtServer starts.
FTP To start/stop FTP server to make it possible to use ftp for file transfer.
Multipath When accessing SAN LUNs as physical devices using virtual KGPSA adapters, the guest operating system (OpenVMS or Tru64) provides multipath redundancy and this setting should remain in the default OFF state. Enable it only when using logical disks with the container files located on SAN storage. The clean option removes all current multipath definitions and generates a new list. NFS To start/stop NFS (Network File System) to make it possible to use NFS for access to remote disks.
Page 16
June 2018 vtServer® Reference Manual v3.2.0
SSH To start/stop SSH to make is possible to open a terminal window on vtServer using SSH.
SMB To enable Windows share access.
SNMP To enable SNMP access
vtScan To start/stop the Vtscan service.
VMware To start/stop VMware tools. This option is only available when vtServer is installed on a VMware virtual machine. The VMware Tools package provides support required for shared folders and for drag and drop operations.
Page 17
June 2018 vtServer® Reference Manual v3.2.0
3.3.12. vtCloud It is possible to run VtServer in the Cloud. When installing in the Cloud you need a Compute Instance. A compute instance is a virtual machine that exists in the cloud. It has a CPU, memory, storage and a network connection. To make vtServer work in the cloud the following is needed: 1) A compute instance with CPU, memory, storage, an IP-address withaccess to the internet. 2) A dedicated vtLicense server, with access to the internet. N.b. The vtLicense Server is usually placed at your local location
When the vtServer is installed on the compute instance, the Cloud setup must be executed to create a VPN connection between the cloud vtServer and the vtLicense server. This must be done on the vtServer in the Cloud, as well as on the local vtLicense server. Before starting the Cloud configuration get the following information, it is essential to complete the Cloud configuration. 1) The port number for the VPN connection. 2) The external IP-address given to the compute instance (the vtServer).
Now complete the next 3 stages (A, B, C)
A. vtServer Cloud Configuration
Go to Cloud Setup in the System Configuration menu and “Enable cloud”.
Read the following warning carefully and select Yes to continue (or No to quit)
Enter the port number to use for the VPN
Page 18
June 2018 vtServer® Reference Manual v3.2.0
For the Cloud management port and for the external internet port eth0, enable dhcp. n.b. If the cloudprovider does not provide a dhcp address (or if you are in a local test-environment), you have to supply your own ip-address for the eth0 (including the correct gateway-address)!
Read the warning carefully and select Yes to continue (or No to quit). You will lose connection to the Cloud instance via previous set IP address. After the VPN is setup you can reconnect to the IP set on clm0
n.b.b. In a test-environment (where your server is a local vtServer), make sure the eth0 adapter is connected to the outside world
B. vtLicense Cloud Configuration
Page 19
June 2018 vtServer® Reference Manual v3.2.0
Now login into the vtLicense server and continue with the Cloud setup on the license-side.
Enable cloud, and read the warning, select Yes to continue or NO to quit
.
Continue with the VPN configuration. Server address is the Internet IP address of the vtServer in the Cloud. Port number is the port used to setup the VPN link to the vtServer in the Cloud.
The cloud interface clm0 must bet set with an local IP address. DHCP can be used to obtain an IP address.
Read the warning and select Yes to continue. The vtLicense server will now setup a VPN connection with the vtServer in the cloud and the vtServer in the cloud will become part of the local network. The vtServer is now accessible on the local network as if it were a local machine.
Page 20
June 2018 vtServer® Reference Manual v3.2.0
C. Security Keys
The VPN between vtServer in the Cloud and the vtLicense server uses default security keys delivered with the product. From the menu a new set of unique keys can be generated. It is recommended to generate new keys to enhance the security of the connection. When the customized keys are not working, reset to the default keys on both sides and connection will be reestablished.
Page 21
June 2018 vtServer® Reference Manual v3.2.0
3.3.13. Snapshots With snapshots it is possible to preserve the state of the system at a particular point in time. When needed, a snapshot earlier made can be used to restore the system to the state when the snapshot is made. Snapshots are only available on disks formatted with the btrfs filesystem. The snapshot utility will scan all available disks to see whether at least one of them is a btrfs disk. When no btrfs disk is available an error message will be shown.
VtServer installations before 3.1.0 are installed on an ext4 formatted partition. To enable snapshots vtServer must be re-installed and the new installation must be on a btrfs formatted disk. Reinstalling will remove the current installation, including all the configurations. So create a backup file before reinstalling vtServer.. By default an automatic snapshot will be made when an update/upgrade is applied to the system. Using the snapshot made before the upgrade it is always possible to revert back to the state before the update/upgrade. Snapshots can be made manually when required. It is advisable to make snapshots before complex and/or large changes are made to vtServer or configurations. To create a new snapshot, select the disk and select Ok.
list To show all the snapshots available
create Create a new snapshot.
delete To delete an existing snapshot.
rename To rename an existing snapshot.
select To select a snapshot and restore to the state of the snapshot.
Page 22
June 2018 vtServer® Reference Manual v3.2.0
3.3.14. Sysinfo To display general system information. Example:
3.4. Shutdown/Reboot These options allow you to perform a shutdown or reboot of the host system. A warning message will be displayed if instances of vtVAX or vtAlpha are running. This message can be overridden manually.
Page 23
June 2018 vtServer® Reference Manual v3.2.0
3.5. Graphics The graphics option displays a menu of options related to the X-Windows environment.
3.5.1. X Server Start Starts the X Server. The display will become black until an application writes data to it. To exit this mode, press ctrl-alt-backspace twice consecutively.
3.5.2. Display This section is only relevant when this host is used as an Alpha workstation, meaning using the keyboard and monitor(s) attached to the host when running a virtual Alpha or VAX. The font option allows choosing between Generic, OpenVMS or Tru64 fonts. In monitor the settings of the attached monitors can be managed. Right-clicking the screen to manage lists the options. Use the menu from this function to switch between functions , save changes or quit this section. Keyboard is used to select the desired keyboard. None means default lk4xx_ps2 or _usb selects that type of keyboard and ps2dec selects a keyboard with all 20 function keys enabled, allowing to use F13 – F20 when pressing right-Alt + F3 (- F10). Mouse allows switching left and right mouse button functions. Parameters is used to configure special X-Server options.
3.5.3. Autostart Starts the X Windows server when the host is booted.
3.5.4. Security This option is used to specify the IP addresses that are permitted to access the vtServer X Windows server. The default values are usually sufficient.
Page 24
June 2018 vtServer® Reference Manual v3.2.0
3.5.5. Advanced This option is used to run vtMonitor in situations where it is not feasible to do so from a separate workstation browser session. The graphics support in this mode is limited. External storage devices such as USB drives or memory sticks must be manually mounted in the vtMonitor storage tab before they can be accessed to import or export files. 3.6. Support The Support menu option initiates a connection to our support center. This connection is used by our support engineers to access the host system to assist with diagnosing or repairing problems. When the support connection is active, a status indication is displayed at top of the vtServer display (see diagram, below). The local administrator retains control of the connection and may disconnect it at any time. The support connection may also be controlled using the Support tab in the vtMonitor Toolbox. The support connection is established using an encrypted link on TCP ports 80, 22, or 443. Most firewalls allow outbound connections using at least one of these ports, so in most cases no special configuration is required to use the support connection. The support connection may only be initiated by the local administrator; it cannot be started by our support engineers. Only initiate a support connection when instructed to do so: we do not monitor for unscheduled connections. This service requires that the vtServer host be connected to the Internet.
When the support connection is active, the start option in the vtServer Remote Support menu will change to stop and the connection status and session ID will be displayed at the top of the menu as well at the top of the screen, making it obvious to the administrator that the link is active. The administrator retains control of the link and may disconnect it at any time.
Page 25
June 2018 vtServer® Reference Manual v3.2.0
4. vtMonitor/vtLicense Management Tool vtMonitor is a tool for managing the vtServer environment as well as vtAlpha and vtVAX configurations and emulator instances. vtMonitor is initiated by using a web browser (Firefox, Internet Explorer, Edge, Chrome, or Safari) to connect to the management address of a vtServer host from any desktop system with HTTP network connectivity to the host system. vtLicense offers a subset of the functionality of vtMonitor (Toolbox capabilities, chapter 8), since it only has to manage the vtLicense hardware. Both product share the same code-base and are therefore both described in this reference manual. When connected to a vtLicense box it identifies itself accordingly in the header bar. The vtServer installation configures the primary network interface (/dev/eth0) for DHCP. If the host is connected to a network with a DHCP server available, the address assigned to the primary interface will be displayed on the console after the user successfully logs in. If the user wishes to use vtMonitor at this point, they may access it using the DHCP-supplied address. When DHCP is not available, the network interface must be configured using vtServer (see Chapter 3) before vtMonitor can be used. After a HTTP(S) connection is established to the vtServer host, the user must sign on before vtMonitor will display any information. Normally, the root account is used; however, additional usernames may be defined. Note: vtMonitor automatically enforces HTTPS for security reasons. The main vtMonitor screen (below) consists of 3 sections:
Header. Prior to login, the header contains only text boxes for entry of the user ID and password. After a successful login, system and user status information is displayed. Configuration Management. The left panel below the banner. Content. The main work area to the right of the configuration management. Each of these sections is described in detail below.
Page 26
June 2018 vtServer® Reference Manual v3.2.0
4.1. Login The vtMonitor login screen is shown below. Normally the root account is used to login; however, additional accounts may be created by the administrator. Hovering the mouse pointer over an input field or control button will display a description of the field or button.
After a successful login, the vtMonitor banner appears as shown below. For security purposes, vtMonitor will disconnect after 30 minutes of inactivity; to disable this timeout, select the disable timeout option under the username.
The vtMonitor display is explained in more detail in the remainder of this chapter. 4.2. Configuration Management A list of all defined vtAlpha and vtVAX configurations is displayed in this section in the left-hand panel of the vtMonitor window. The colored indicator shows the status of a configuration (vtVAX only running and inactive): Configuration is running; Configuration started, awaiting input at the SRM console prompt Configuration inactive; Configuration deleted, awaiting completion of the operation; Configuration has crashed and is producing a dump file. It will change to when completed; Indicates that this configuration is consuming a Disaster Recovery License and that corrective maintenance is required to restore the availability of the primary license. Indicates the license this configuration is using will expire within the next 10 days. (blinking) Warning that this configuration lost access to a license and will stop (16 hours after the loss was detected), unless access to the license is restored again. The letter A to the right of the status indicator indicates that auto-start is enabled: the virtual system will start automatically when the vtServer host is booted. The configuration list is refreshed every 5 seconds. Selecting a configuration name will switch the main Work section of the vtMonitor display to the Configuration tab and the selected configuration will be displayed and can be edited, if desired. Right-clicking on a configuration name will cause a context- sensitive pop-up menu to appear (see figure, right). Start and Stop control the execution status of the virtual system.
Page 27
June 2018 vtServer® Reference Manual v3.2.0
Show Log opens a new tab in the vtMonitor work area to display the log file contents. Export downloads an archive containing the configuration information and log files for the selected virtual system to the user’s desktop system. Import adds/restores prepared/saved configurations from a file on your workstation to this configuration list Rename changes the name of an existing configuration. Delete removes the configuration and all associated log files from the host. Auto-start toggles the auto-start status of this configuration. When the selected virtual system is running, additional options to connect to the OPA0 and/or COM2 console ports will be displayed. Connecting to a console port will cause a new browser window or tab to be opened for the console interface (see figure, below).
Various console display characteristics, including screen color, cursor blinking, and on-screen keyboard, can be configured by right-clicking in the console display area. The virtual system consoles may be accessed with any terminal emulator with TCP capability, such as PuTTY, using the vtServer host management IP address and the port number defined in the emulator configuration.
Page 28
June 2018 vtServer® Reference Manual v3.2.0
5. Configuring Virtual Alpha Systems 5.1. Buttons Description
Save Saves the configuration that has been edited. New Creates a new configuration. You will be presented a list of computer models to select from, before it continues to an empty configuration template.
5.2. Comment Box Text entered in the comment box will be used for documentation purposes only. Special characters (e.g., é, õ, ä) may be used. 5.3. vtAlpha Configuration Name Specify the name that will be displayed in the configuration list. Changing the name of an existing configuration saves a copy of that configuration under the new name; the configuration is also retained under the original name. Use the rename option in the quick menu of the configuration list to rename the configuration without making a copy. When an existing name is used, the old configuration is overwritten without warning. Default: New Alpha-system-type. 5.4. Hardware Model A default value is provided when a new configuration is created. The hardware model may be changed to a different model in the same product class by right-clicking on the model name and selecting the desired model from the quick menu. To configure a model from a different product class, a new configuration must be created. For example, an AlphaStation 500 configuration can be changed to an AlphaServer 800 but not to a DS10. Default: selected at creation time This option has two sub options, both of which can be set to match the values of the physical Alpha system being replaced when application software checks these values for license validation. Only change the sub options under guidance of your vtAlpha support organization. SMM (System Marketing Model) Default: blank Custom Model Name Default: blank
Page 29
June 2018 vtServer® Reference Manual v3.2.0
5.5. Advanced Options Less frequently used configuration options are grouped under this heading to provide a cleaner display. Click on [+] to expand the options in this group. Log File Name of the log file to be used for this configuration. The same log file name may be used in different configurations without conflict. Default: logfile.log System Trace Level Used for debugging purposes only. The trace level is a number between 0 (off) and 9 (inclusive) that controls how much data is recorded. Tracing degrades performance; therefore, the Trace Level setting should remain set to 0 unless directed by your vtAlpha support organization. Default: 0 CPU Acceleration Controls software acceleration of virtual CPU performance. CPU acceleration is enabled by default; it is disabled when application code contains timing dependencies that are triggered by running on a faster CPU. This setting should only be changed upon request of your vtAlpha support organization. This setting has no effect on vtAlpha-AS instances, which do not support CPU acceleration. Default: 1 (on) JIT Pool To be used only under guidance of your vtAlpha support organization. Default: blank JIT Processors To be used only under guidance of your vtAlpha support organization. See also Virtual CPUs for details about this subject. Default: 0 n.b. the jit_pages parameter has been removed as of version 3.2, it will now auto auto-tune NVRAM Specify the name of a file to be used to load the NVRAM. Please use only on the advice of your vtAlpha reseller or support organization. Default: nvram.dat 5.6. QBB In GS-series systems (GS80, GS160, GS320, GS1280, and ES80), CPU, memory, and PCI busses are grouped in in structures known as Quad Building Blocks (QBB). Each system is composed of one or more QBBs. Each QBB may be configured with up to 4 CPUs, 32 GB or memory, and 32 PCI slots (8 busses of 4 slots each). The configuration for the console serial ports OPA0 and COM2 is contained in QBB0, which is present in all GS configurations. Additional QBBs, up to a model-dependent maximum, may be added by right-clicking on any existing QBB and selecting the option to add the next sequential QBB unit. Existing QBBs may be removed by right-clicking on the QBB to be removed. Note that QBB 0, PCI bus 0, slot 0 is already occupied by a default device (I/O-module) and will not be shown in the virtual Alpha configuration. Page 30
June 2018 vtServer® Reference Manual v3.2.0
5.7. Virtual CPUs Specify the number of Alpha CPUs to virtualize. This number must be the same or less than the number of CPUs licensed for this configuration. Default: 1
The number of virtual CPUs is one of the two factors that has a direct relationship to the assigned host resources and must therefore be considered when sizing the host computer. Every virtual Alpha CPU requires a full host CPU-core to run. To facilitate the Alpha CPU process vtAlpha needs 50% extra CPU capacity on the host for adjacent and supporting tasks. This means every virtual Alpha CPU requires 1.5 Host CPU-core, at a minimum. For most vtAlpha implementations this will be sufficient. However, for Alphas that were exercised harder it might be necessary to assign extra host CPU-power to keep up with the high-performance demand of the Alpha-based software. This can only be assessed by running the user applications. vtAlpha allows to manually assign more host CPU-resources to a certain virtual Alpha by using the "JIT Processors" parameter in the vtAlpha configuration (Advanced Options). The default value of this parameter is 0, meaning vtAlpha will claim one additional host CPU-core for every vtAlpha instance in the product range vtAlpha-AS - vtAlpha-ES. In case of vtAlpha-GS it claims one additional host CPU-core per QBB. When manually assigned with a value other than 0 vtAlpha will allocate that number of host CPUs instead. This allows assigning more than the default setting (note: in the case of vtAlpha-GS you can assign less than what is allocated by default). vtAlpha-AS to vtAlpha-ES: Alpha CPUs + 50% + additional JIT processes vtAlpha-GS: Alpha CPUs + 50% + QBBs unless the JIT Processor parameter is used, in that case the following formula applies Alpha CPUs + 50% + JIT processors
5.8. CPU Details Set hardware information that may be used by third-party software license verification mechanisms. Available options are: - CPU type (quick menu) - CPU variant (quick menu) - CPU revision - CPU Serial number(s) that are to be copied from the original Alpha hardware These values should be set only with the guidance of your vtAlpha support organization.
Page 31
June 2018 vtServer® Reference Manual v3.2.0
5.9. Memory Amount of Alpha memory (in MB) to be virtualized (1 GB = 1024 MB). The number displayed in parentheses in this field is for display purposes only. The Memory Size sub-option is used to specify the amount of memory to be configured. vtAlpha supports up to 32 GB (32768 MB) of virtual Alpha memory. The maximum amount of memory supported on some Alpha models is less than 32 GB. Please check the Software Product Description (SPD) for the operating system and version being used to identify the maximum amount of memory allowed. For each vtAlpha emulation instance running simultaneously, the total host memory required is (1.25 * the emulated Alpha memory) + 1 GB (for the Host). If sufficient memory is not present, the emulation will not start. Default: 128 Memory Base is reserved for future use. Default: 0 5.10. OPA0 / COM2 vtAlpha virtualizes the 2 serial line ports that were available on the Alpha computer systems: OPA0 and COM2. Each of these virtual serial ports can be attached to a TCP/IP port or to a physical serial interface (e.g., /dev/tty1). Default: TCP/IP ports :20001 and :20002
The details are presented collapsed; open the item to view/change details.
Page 32
June 2018 vtServer® Reference Manual v3.2.0
Logfile: When a file name is specified, all data transferred on the virtual serial interface will be logged in that file. When this field is blank, no data is logged. Default: blank Password: This field is used to specify a port access password that must be provided each time a new connection is opened to the port. A password is strongly recommended for console ports that are attached to IP connections, which provide much wider access than a physical serial line connection. The passwords are stored in encrypted format and cannot be displayed once set. Default: blank Options: Special serial line options (raw/nodelay). To be used under guidance of the vtAlpha Support Organization. Default: blank Trace Level: Debug purposes, only to be used under guidance of your vtAlpha Support organization. Default: blank Baud Rate: Specify the baud rate for virtual serial interface connected to a physical serial interface. Select the correct baud rate from the quick menu. Default: blank Timestamps: Specifying any value for this parameter causes a timestamp to be added to the log file entries. Default: blank 5.11. PCI Bus The number of available PCI busses and the number of slots on each PCI bus vary depending on the Alpha system model being configured. Virtual storage, network, or serial line adapters may be configured in any open slot.
NOTE: vtAlpha uses the same I/O adapter configuration rules as the physical Alpha systems. These rules, which vary depending on the Alpha hardware model, are provided below:
For vtAlpha-AS and -BS models, adapters are configured in the following order: Slot 2, 0, 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14. For example, SCSI adapters configured in slots 0, 1 and 2 will be designated PKB, PKC, and PKA, respectively. If the adapters are configured in slots 0, 1, and 3, they will be designated PKA, PKB, and PKC, respectively.
For vtAlpha-CS models, the configuration sequence is slot 0, 1, 6, 7, 8
For vtAlpha-DS and –ES models, the sequence is bus 1, slot 0 - 5, then bus 0 slot 0 – 3.
Page 33
June 2018 vtServer® Reference Manual v3.2.0
5.12. PCI Slot
Each PCI-slot can host one (1) PCI adapter. Now the following PCI adapters are available: KZPSA SCSI adapter, which provides up to 120 SCSI devices KGPSA Fibre Channel adapter, which provides up to 32.767 devices VTDSK Virtual Device adapter (MSCP. DSSI, IDE, RAID virtualization) EI1000 Gigabit Ethernet adapter DEGXA Gigabit Ethernet adapter DE600 Ethernet adapter DE500 Ethernet adapter DE450 Ethernet adapter DE435 Ethernet adapter PBXDA Serial Lines adapter (8 lines) Position the mouse pointer over a PCI slot and right-click to display a context sensitive menu with options to add or remove a device from the slot, depending on the current state.
Page 34
June 2018 vtServer® Reference Manual v3.2.0
5.13. Ethernet Adapter vtAlpha supports virtual EI1000, DEGXA, DE600, DE500, DE450, and DE435 Ethernet adapters:
Normally, the same type of Ethernet adapter present in the physical Alpha system will be configured in vtAlpha to prevent the device names from changing. Note that the speed at which data is transferred over the network interface is determined by the physical network adapter being used and the physical network utilization; the speed of the virtual network adapter is ignored. The virtual Ethernet adapter has 4 configuration options: Host adapter or virtual network device to connect to (eth0, eth1, avt0, bond0, etc.). MAC-address. Rarely necessary, only needed when certain software licenses are tied to the MAC-address of the Ethernet adapter of the system it was running on. Adapter Trace Level and Device Trace Level. Parameters used for debugging purposes only. Default value = 0 (no tracing). Enabling tracing will add additional overhead to all network transfers, which will impact the performance; therefore, the value of this parameter should be changed only when requested by your vtAlpha support organization. It is recommended that one physical network interface be provided for the vtServer host communications in addition to one physical interface for each virtual network interface. 5.14. Serial Lines Adapter When more than two virtual serial lines (OPA0 and COM2) are required, virtual PBXDA (8-line) serial interfaces may be defined. A maximum of 8 PBXDA adapters are supported, for a total of 64 additional serial lines. To add a virtual PBXDA, select one from the list of available adapters in the right-hand pane (double-click adapter or use the "Add Device"' button). By default, all line details are shown unopened, with the Device value between brackets to maintain the overview of the configuration. To configure the adapter details, open any of the lines you want to change. The Line Numbers per virtual PBXDA are fixed and cannot be changed. Line Device: a TCP port number (e.g., :12345) or physical device name (e.g., /dev/ttyS7). Right mouse click brings up a list of physical devices that can be connected. Duplicate assignments can cause line traffic problems. Default: blank
Page 35
June 2018 vtServer® Reference Manual v3.2.0
Options: Sets line specific characteristics. "raw" and/or "no_delay" can be added from the dropdown list or entered manually. (under guidance of your vtAlpha support organization). When using "raw" on a physical serial port there will be no Xon/Xoff flow control, so the communication will be transparent. When using "raw" on a network connection the data will not be modified to match the telnet protocol, so communication will be transparent. Note: Option "raw" applies to both physical serial line and network connection When using "no_delay" on a network connection characters will be passed on immediately when collected. By default, the data will go through a small buffer which can introduce a brief delay before the data is sent. Note: Option "no_delay" applies to network connection only Default: blank Line Trace Level: Use only under guidance of your vtAlpha support organization. Tracing degrades performance and should only be used when troubleshooting a problem. Default: 0 Logfile: The name of the file where all the line traffic will be logged. Note that logging slows down the line performance and should be used with caution. Default: blank Baud Rate: Sets the line speed to an assigned value. Click on the right mouse button for a list of values. Time Stamps: When assigning a log file to this line, this parameter adds a time stamp to each logged entry. Default: blank Note: It is necessary to re-install or reconfigure the VMS serial line drivers when using virtual PBXDA devices. See section 10.10 (Installing Serial Line Drivers in OpenVMS) of this manual for details.
Page 36
June 2018 vtServer® Reference Manual v3.2.0
5.15. SCSI Adapter The virtual KZPBA adapter is the interface between the virtual Alpha system and the physical or logical storage devices. The device name prefix of each adapter (PKA, PKB, etc.) is determined by the virtual Alpha model and the PCI slot used. To keep the device names the same on the physical and virtual Alpha systems, the virtual Alpha bus configuration should be identical to that of the physical system.
The following SCSI devices are supported: - Physical SCSI disks. The vtAlpha disk maps to a physical disk device on the host. - Logical SCSI disks. The vtAlpha disk maps to a container file in the host file system. - Physical SCSI tapes. Direct attached tape device. - Logical SCSI tapes. Implemented as container files in the host file system. Can be dismounted and separately backed up after completion. - Generic SCSI device. Can be any kind of device as far as the host computer is concerned. The host passes any traffic through to the device; the guest operating system (OpenVMS or Tru64) must have the appropriate drivers for that device. The Logical and Physical CD-ROM options create a logical or physical read-only disk, respectively. When viewing a saved configuration, the CD-ROM devices will be displayed as regular disks with the appropriate characteristics. To add SCSI devices, select the Storage Bus item of the virtual KZPBA adapter, then select the desired storage device from the quick menu. There are three configuration options for devices connected to a virtual KZPBA: - Target address. Click on this field with the right mouse button to display a list of addresses (0- 15). The address selected will be the first 1-2 digits of the device unit number. NOTE: the target address used by the SCSI adapter may not be used for the devices. - LUN number. Click on this field with the right mouse button to display a list of addresses (0-7). - Trace Level. Parameters used for debugging purposes only. Default value = 0 (no tracing). Enabling tracing will add additional overhead to all data transfers, which will impact the performance; therefore, the value of this parameter should be changed only when requested by your vtAlpha support organization.
Page 37
June 2018 vtServer® Reference Manual v3.2.0
5.16. Fibre Channel Adapter The virtual KGPSA adapter connects to the Fibre Channel storage elements or SAN that need to be connected to the virtual Alpha.
When a host name is assigned (see KGPSA definition in PCI slot 0, above), the SAN storage controllers will present the storage configuration to vtServer and changes to the configuration will be detected automatically. When the host name is defined, devices may not be manually configured; previously configured devices will be retained in the configuration file but will be ignored. This is the preferred method for configuring SAN storage. When the host name is omitted (see KGPSA definition in PCI slot 1, above), each storage device to be accessed must be manually defined. The following types storage devices are supported: Physical disks. Each accessible LUN on the SAN is available as a device on the vtServer host and as a virtual disk on the vtAlpha guest. Logical disks. Container files located on the SAN may be configured as logical disks which are presented to the vtAlpha guest OS as individual devices. Physical tapes. Direct attached tape device.
The virtual KGPSA adapter has 6 parameters that can be modified:
Host name. Name of the Fibre Channel adapter; when assigned the adapter will manage the available storage elements1. Node name. Node hardware address of the FC adapter. Port Name. Port hardware address of the FC adapter. Shared Adapter. Set to yes when this adapter is shared with another virtual Alpha. Options. Special options, to be used under guidance of your vtAlpha Support Organization Trace Level. To be used for debugging purposes as requested by your vtAlpha support organization; should be 0 for production situations. LUN Map. Mask devices and change device IDs:
Page 38
June 2018 vtServer® Reference Manual v3.2.0
Format: [portid=xxxxxx][productid=xxxxxx][,default][,lun:id],[lun:id,...][;portid=xxxxxx...] portid=10300,default;portid=10400,1:2;portid=10800,default,1:55,7:88 Example: portid=10300,default,1:34,5:48 This means that for controller with id 0x10300 we will map all LUNs one on one to an identifier (lun 1 = id 1, lun 2 = id 2, etc.). After that an optional list of mappings may follow. In this case LUN 1 will be mapped to id 34, and LUN 5 to id 48. The latter 2 mappings will overrule the default mapping. Example: productid=A6218A,default,1:34,5:48 This overrules the LUNs for the device with the SCSI product identification A6218A.
1 The node name of the destination Fibre Channel adapter can be found in the Host section of the Toolbox menu. Example:
Fibre Channel devices:
Controller: Emulex LP7000 FV3.30A7 DV8.3.25 Host name: host8 Node name: 2000-0000-c920-e9db Port name: 1000-0000-c920-e9db Port type: NPort (fabric via point-to-point) Speed: unknown State: Online
Enter the Host name (host8 in this example) or the unique Node name (2000-0000-c920-e9db) in the Host name field of the virtual Alpha configuration specifications.
Note: SAN storage configuration changes will be automatically detected by the vtServer host. OpenVMS does not support automatic storage reconfiguration: the SYSMAN AUTOCONFIGURE command must be used to make the changes visible to the OpenVMS operating system. This is an OpenVMS limitation that applies to both physical and virtual Alpha configurations.
Page 39
June 2018 vtServer® Reference Manual v3.2.0
5.17. Virtual Device Adapter The Virtual Device adapter (VTDSK) is a vtAlpha-specific feature that provides the capability to present storage of one type to OpenVMS as a different type of storage. The most common use is to create disk devices with the same names as those on the physical system being replaced. Allocation Class: Set to the value expected by OpenVMS Default: blank
Host Name: Set to the value expected by OpenVMS Default: blank
The following storage device types are supported:
Storage type Media Type Storage device name MSCP PU DUcnnnn DSSI PI DIcnnnn IDE PQ DQcnnnn RAID PR DRcnnnn SCSI PK DKcnnnn Fibre Channel [1] PG DGcnnnn
[1] The VTDSK adapter provides limited support for Fibre Channel devices: features such as host name and device autodetection are not supported. For full Fibre Channel support, use the virtual KGPSA adapter. Example: defining a virtual storage adapter with type PU (MSCP) will result in all virtual disks attached to that adapter presenting to OpenVMS with device names DUxnnn (e.g., DUA100) Devices supported by the VTDSK virtual device adapter are limited to physical and logical disks and CD-ROMs.
The desired virtual device type is defined in the Type field, as shown below:
Allocation class correlates with the OpenVMS Allocation class (refer to VMS documentation).
Page 40
June 2018 vtServer® Reference Manual v3.2.0
Use of devices attached to the vtServer virtual disk adapter requires installation of a custom driver on the OpenVMS guest system. This driver is located on the vtTools logical disk (vttools_alpha_vms.vdisk), which is provided in the /tools directory of every vtServer distribution. The VTDSK driver requires a minimum OpenVMS version of 6.2-1H3 for data disks and version 7.0 for the system boot disk.
To install the VTDSK driver, a logical disk mapped to the vtTools container file must be temporarily added to the system configuration. The driver may be installed directly from the vtTools disk, as shown below, or it may be copied to one of the permanent disks and installed from there.
$ mount dka100: vttools %MOUNT-I-MOUNTED, VTTOOLS mounted on _VMS84$DKA100: $ product install /source=dka100:[vtdsk010] * Performing product kit validation of signed kits %PCSI-I-CANNOTVAL, cannot validate DKA100:[VTDSK010]AVT-AXPVMS-VTDSK-V0100--1.PCSI;1 -PCSI-I-NOTSIGNED, product kit is not signed and therefore has no manifest file The following product has been selected: AVT AXPVMS VTDSK V1.0 Layered Product [Installed] Do you want to continue? [YES]
After installing the VTDSK driver a reboot of OpenVMS is required to add the virtual disks to the configuration.
Page 41
June 2018 vtServer® Reference Manual v3.2.0
5.18. Storage Devices
The following types of storage devices are available in vtAlpha:
Physical Disk Logical Disk Physical Tape Logical Tape (for more on logical tapes read the chapter “TapeMGR [for managing logical tapes]”) Generic SCSI device
Physical Disks are directly attached to the vtServer host and accessed by vtAlpha as a single device. It is possible to connect SCSI drives from the Alpha system directly to the vtAlpha host. We recommend that such configurations be limited to migrating data to new drives, because the older mechanical devices are generally slower and have much higher failure rates.
Logical Disks are image copies of the original disks that are stored as container files on the storage that is attached to the host computer. The container files for logical disks may be stored on local drives or on shared storage such as iSCSI, NAS, or SAN.
Every attached storage device has 3 main options that can be modified and a series of details, depending on the type of device:
Target address. The address this adapter claims on the SCSI-bus of the adapter it is attached to. These numbers (0 -15) need to be unique per storage adapter, except for the target address that is allocated by the KZPBA itself. Select from the right mouse click option list. LUN number. Logical Unit Number on the Target address. A number from 0 - 7. Default = 0. A device on the first storage adapter with Target Address 1 and LUN 3 will appear in your OpenVMS or Tru64 system as DxA103. Select from the right mouse click option list.
Page 42
June 2018 vtServer® Reference Manual v3.2.0
Identifier. Only presented for devices that are attached to a Fibre Channel adapter. Value 1 – 32767 which overrides the value of the LUN-number. This identifier specifies the unit number in OpenVMS/Tru64. Trace Level. Parameters used for debugging purposes only. Default value = 0 (no tracing). Enabling tracing will add additional overhead to all data transfers, which will impact the performance; therefore, the value of this parameter should be changed only when requested by your vtAlpha support organization.
The following device parameters will be presented depending on the type of device.
Device location. Mandatory for every device. The location can be selected from the right mouse click option list, or can be entered manually. Right mouse click presents the list of available partitions. Select the partition your disk image is on and then select the disk image in the window that opens at the right-hand side. Clicking on a file ( ) selects it and copies the data path in the configuration file. Selecting a directory ( ) opens that directory. Selecting directory ( ..) moves up one directory level. Items marked with are compressed/zipped files and cannot be connected to a storage adapter. An attempt to do so will result in an error message and an abort of the action. Maximum File Size (logical tapes only). Specify the maximum size in MB the container file can expand to. Tape Format (logical tape only). Alternate formats besides the default are MTD, LM (LD/LMDRIVER) and SMA (the format that is used by CHARON). Tape Compression (logical tape only). Set to yes it will compress the tape file during the write operation. Default = no. Read-Only. Select from the right mouse click option list. Default = no. Autoload (logical tape only). When set to no, tapes must be manually loaded using the OpenVMS TAPEMGR utility. See the Tips sections for details. Default = yes. Removable device. Select from the right mouse click option list. Default = no. Shared device. Select from the right mouse click option list. Default = no.1 Read-Cache on. Select from the right mouse click option list. Default = no.2 Write-Cache on. Select from the right mouse click option list. Default = no.2 TruCluster Support. Select from the right mouse click option list. Default = no. Only relevant when this logical disk is member of a TruCluster. Vendor-id. ID of the vendor of the original device. Generated automatically when known device type. Value can be changed. Disk type. Generated automatically when known device type. Value can be changed Disk geometry (size, cylinders, sectors, tracks). Can be set manually. Generated automatically when known device type. Revision Level. Rarely used. Default = blank. Serial number. Rarely used. Default = blank. 3 WWID. WWID number for this logical disk. 3
1 Logical disks on external storage cannot be shared.
2 Enabling these cache options may improve the I/O performance for the device. N.B. Sharing must be disabled when a device is shared with a virtual Alpha instance running on a different vtAlpha host (e.g., in a cluster). Sharing may be enabled when a device is not shared or is shared with a cluster node running on the same vtAlpha host to improve I/O performance.
3 A unique value is generated when adding a logical device to a configuration. The content of this field can be manually edited. Page 43
June 2018 vtServer® Reference Manual v3.2.0
Physical Tapes are tape drives directly attached to the host and are accessed by vtAlpha directly. It is possible to connect SCSI tape drives from the Alpha system directly to the vtAlpha host. We recommend that such configurations be limited to migrating data to new drives, because the older mechanical devices can eventually be replaced with logical tape images.
Logical Tapes can be used to virtualize a physical tape drive and use tape container files instead of physical tape cartridges. By default, a logical tape container file will grow as data is written to it. When an unload command is sent to the virtual tape drive, the tape will be disconnected from the emulator and the container file may be copied or moved. When the Autoload parameter is enabled, the tape will be loaded automatically when a VMS MOUNT or INITIALIZE command is executed. When manual control of tape loading and unloading from the VMS system is desired, set the Autoload parameter to off and use the TAPEMGR utility to control the tapes. (chapter: “TapeMGR [for managing logical tapes]) Generic SCSI Device can be any kind of device as far as the host computer is concerned. The host passes SCSI traffic ‘raw’ to the device and expects OpenVMS or Tru64 to have the appropriate drivers to control the device (e.g. SCSI-to-GPIB converter)
6. Configuring vtVAX The vtMonitor Configuration tab work area has two control buttons, as shown below:
Save Save the configuration presently being edited. New Create a new configuration. A list of available hardware models will be displayed (see figure below). After the desired model is selected a configuration editing screen will be displayed. The operating system version displayed to the right of each model name is the lowest version of the OS supported for that model in vtVAX or vtAlpha.
Page 44
June 2018 vtServer® Reference Manual v3.2.0
6.1. Configuration Name This field specifies the name that appears in the vtMonitor configuration management list; it has no effect on the running instance. The configuration name may consist of alpha-numeric characters, blanks, dashes, and underscores. Using the name of an existing configuration will result in the existing configuration being overwritten without warning when the current configuration is saved. Changing the name of an existing configuration will result in a new copy of the configuration being created; the original copy must be deleted manually, if desired. To directly rename an existing configuration, right-click on the configuration name in the configuration list and select the Rename option.
6.2. Environment: License Group A License Group specifies which vtVAX license will be used when this configuration is started. The general format for License Group options is as follows: vtVAX_{memory size}{instruction caching indicator}, or vtVAX_{model number} (VAX 7600-series) Examples: . vtVAX_128 – vtVAX with 128MB memory and instruction caching disabled . vtVAX_128IC – vtVAX with 128MB memory and instruction caching enabled . vtVAX_7610 – VAX 7610 6.3. Environment: Temporary License Temporary licenses are a special class of licenses that are distinct from usage-based (decremented minutes) or date-based (annual or permanent) licenses. Temporary licenses are used in situations where the same license server(s) must be used for production and evaluation licenses. The Temporary License configuration setting is used to force a vtVAX instance to use a temporary license at startup; when the Temporary License setting is disabled, the vtVAX will ignore temporary licenses, even when no regular license is available. A vtVAX instance that is using a temporary license when the license expires will search for an available temporary license to replace the expired license; if none is found, it will then search for a regular license. The emulation instance will not restart with a regular license unless the Temporary License configuration setting is first disabled. 6.4. CPU: VAX Model When creating a new configuration, the VAX Model field is set to be the same as the model that was initially selected. The current model may be changed to another model in the same family by right-clicking on this field and selecting the desired model from the drop-down menu. It is not possible to change an existing configuration to a model in a different family (e.g., a VAX 3900 to a VAX 7600): a new configuration must be created, and the existing configuration deleted, if desired. When licensed software requires specific hardware identification to run you can use the vtVAX vtSID utility to set that exact type. See Chapter Fout! Verwijzingsbron niet gevonden. for details.
Page 45
June 2018 vtServer® Reference Manual v3.2.0
6.5. CPU: Memory This is the amount of VAX memory (in MB) to be configured. The maximum that can be configured is limited by the model selected and the vtVAX license. Some virtual VAX models can be configured with more memory than was supported on the physical processor, vtVAX license permitting. Such configurations may not be supported. 6.6. CPU: NVRAM file Physical VAX processors use a non-volatile RAM (NVRAM) to store various console settings such as the default boot device and default boot options. vtVAX uses a disk file to emulate the console NVRAM. This field defines the name of the NVRAM file. The NVRAM file is stored in a configuration-specific directory, so the same name may be used in multiple configurations without conflict. The NVRAM file name should be changed only when requested by your vtVAX support organization. 6.7. CPU: Auto Boot The Auto Boot parameter defines whether the configuration will automatically boot when the configuration is started. The default is Disabled, which causes the system to halt after completion of the power-on self-tests (POST). The Boot command must be issued manually at the console to start the virtual VAX system. The Auto Boot option is available only on system models that supported this feature. 6.8. CPU: EcoMode EcoMode (Energy conservation Mode) is a vtVAX configuration setting that reduces power consumption by allowing the host system’s physical CPUs to idle when the corresponding virtual VAX CPU is idle. Depending on the CPU utilization by the virtual VAX system, EcoMode can provide considerable savings in power consumption and heat generation, reducing operating cost and increasing the reliability and lifetime of the physical hardware. The actual savings achieved using EcoMode will vary depending on the workload and physical hardware; in one measured test, EcoMode provided over 25% reduction in power consumption over vtVAX without EcoMode. Enabling the vtVAX EcoMode option on virtual VAX systems with high CPU and/or I/O utilization can result in significant performance degradation. EcoMode should be used only on systems that are idle a significant portion of the time. Note: This restriction does not apply to vtAlpha Eco App. EcoMode is controlled by a configuration setting under the CPU group. The default state is disabled. 6.9. CPU: Instruction Caching The vtVAX Instruction Caching (IC) feature provides improved performance by caching the VAX code instruction stream in memory to provide faster access at execution time. Instruction caching is a licensed vtVAX option; if an IC license is not available, this setting is ignored. Page 46
June 2018 vtServer® Reference Manual v3.2.0
By default, Instruction Caching is enabled when an IC license is selected. In most cases, disabling IC will have a noticeable impact on system performance. For this reason, IC should be disabled only when requested to do so by your vtVAX support organization. 6.10. CPU: Instruction Delay The Instruction Delay and Instruction Delay TMO parameters are used together to cause the vtVAX emulation to run at a slower than normal speed where the application code has timing dependencies that are violated when run on a CPU that is much faster than the original VAX system. Instruction Delay determines how much slower the emulated CPU will be allowed to run: the larger the value of this parameter, the slower the system will run. The default value for Instruction Delay is 0, which allows the emulator to run at full speed. This should be changed only as directed by your vtVAX support organization. 6.11. CPU: Instruction Delay TMO The Instruction Delay TMO parameter specifies the duration (in seconds) that the Instruction Delay is applied to the vtVAX emulation. In many cases the timing dependencies that necessitate the delay occur only during the system or application startup and the system can be run safely at full- speed after that point. The default value of 0 indicates there is no timeout (i.e., the instruction delay will be applied continuously). The Instruction Delay TMO parameter should be changed only at the direction of your vtVAX support organization. 6.12. Console: OPA0 This parameter specifies the TCP port that will be used for the system console device (OPA0). It is present only on hardware models such as the MicroVAX II that do not use a TTA device for the console. The default port is 10000. 6.13. Console: Break Key The break key is a key or sequence that, when entered on the console terminal, will immediately halt the system and display the console prompt. When the break key is disabled the system can be halted by right-clicking on the configuration name in the configuration control area of the vtMonitor display and selecting the Halt option from the menu. The default setting for the break key is Ctrl-P; the alternate is F5 (located on the top row of most Windows-compatible keyboards).
6.14. Console: Console Password The Console Password is used to prevent unauthorized users from accessing the VAX system console and to prevent network port scans from inadvertently halting the VAX system. When the Console Password is set, pressing the ENTER or RETURN key will cause a Password prompt to be displayed. After three consecutive incorrect passwords, the connection will disconnect after a timeout period and the user must establish a new connection to the TCP port. Valid characters for the console password are A-Z, a-z, 0-9,! (exclamation mark) and – (dash). Page 47
June 2018 vtServer® Reference Manual v3.2.0
6.15. TTA Lines: TTAx VAX models that support TTA devices (e.g., VAX 4000/100) use TTA3 as the system console; TTA0-TTA2 are general-purpose serial ports. The configuration menu contains a text entry dialog box for each TTA device which is used to specify the TCP port or physical serial communication interface used to access the corresponding virtual serial interface. Default: 1000n, where n is the TTA unit number (0-3) (see diagram, below).
6.16. vtVAX Storage vtVAX emulates DSSI, MSCP, and SCSI storage controllers and attached disk and tape devices. The controllers available to be configured depend on the VAX system model being emulated. Generally, the virtual storage configuration rules are the same as those of the corresponding physical system. Each virtual storage device must be associated with a corresponding physical storage element, which may be a logical or physical device. 6.17. Physical Devices Physical storage elements must be of the same type (disk or tape) as the corresponding virtual unit. Only SCSI physical tape drives are supported. Physical disks may be directly connected SCSI, SAS, or SATA; USB, DVD or CD (read-only); NAS; SAN; or cloud disk, with the constraint that they must map to the drive itself or a logical unit presented by a SAN or NAS; partitions of directly- connected physical devices may not be used as a physical storage element. When using physical disk devices, keep in mind that the device will be formatted with an OpenVMS file system (usually ODS-2), which will most likely not be readable on a non-VMS system; that the maximum disk size supported by older versions of OpenVMS on VAX are significantly smaller than the size of modern disk devices; and that the space beyond that used by the virtual drive will not be accessible. 6.18. Logical Devices
The following types of storage devices are available in vtVAX:
Physical Disk Logical Disk Physical Tape Logical Tape (for more on logical tapes read the chapter “TapeMGR [for managing logical tapes]”)
Logical storage devices (disk or tape) are a container files that hold all the data stored on the device. The container file is stored in a directory that is part of the host’s file system and may be copied or moved when the associated virtual device is not mounted. The container file may be stored on any supported disk device mounted on the host: directly connected SCSI, SAS, SATA, USB, DVD or CD (read-only), NAS, SAN, or cloud. Logical disks, which often have a file type of .vtd or .vdisk, are created prior to use. New logical disks can be created using vtMonitor (for details, see the description under the Storage tab in this manual) or existing logical disks, such as those created on OpenVMS systems using LDDRIVER may be copied to the vtServer host system. It is recommended that logical disk container files be Page 48
June 2018 vtServer® Reference Manual v3.2.0
stored in a different partition or on a different disk than the vtServer software installation, so they will not be affected if the software must be reinstalled. Logical tape container files are created automatically by vtServer the first time they are accessed by a running vtVAX or vtAlpha emulation. Currently logical tape container files must have a file type of .vtt or .vtape to be properly recognized as a Tape by vtVAX. 6.19. Storage Configuration Parameters Many of the storage configuration parameters are common to multiple storage types: - Device Location specifies where the data for the virtual device is stored. Detailed instructions for using the Device Location field are provided in the next section. To set or modify this value, right-click on the data field and select the appropriate option from the menu. For physical disks and tapes, you will select a device visible to the host; for logical disks and tapes, you will specify the container file by browsing the host’s file system. - Media Type specifies the two-letter prefix of the device name (DU, DI, or DU). This can be used to match the device name to the device names on the physical VAX system. - Write Lock prevents the unit from being modified by the VAX system. - Buffering improves the performance of I/O transfers by buffering data in memory. - Unit ID overrides the default unit number for the device, providing more flexibility in matching the virtual system configuration to that of the system being replaced 6.20. Specifying Device Location The Device Location field is a text box that may be partially or completely populated using menu navigation; when configuring virtual tapes, at least part of this field much be entered manually.
The Device Location field is initially populated with the text “select from menu” as shown in the figure to the left. Right-clicking on this text causes the pop-up menu, also shown on the left, to appear.
To configure a physical disk or tape, click on the appropriate option in the menu. A new panel will be created on the right side of the vtMonitor display where a list of available devices will be displayed. Click on the desired device to select it. To configure a logical disk or tape, click on one of the directories shown in the menu (with the folder icon on the left). If there are no directories shown, you must first use the vtMonitor Storage tab to mount the file system where the container files will be stored. After clicking on a directory in this menu a new panel will be created on the right side of the vtMonitor display where the files and directories contained in the selected directory will be displayed. To navigate to a subdirectory, successively click on the desired name in the new panel until you reach the desired directory. When you are using an existing container file as the logical device, click on that file name in the panel. The Device Location field will contain the full path to the file. When the container file does not exist, as is the case with a new logical tape, after navigating to the directory where you wish to create the file, click inside the Device Location field so that the cursor is at the end of the file path (the last character should be a slash (/)) and type in the name of the new container file. The file type of a logical tape file must be ‘.vtape’; for a logical disk we recommend ‘.vtd’ or ‘.vdisk’. Press the TAB key to exit the text input field. Please pay careful attention to the controller-specific configuration instructions below, especially when configuring logical tape devices. Page 49
June 2018 vtServer® Reference Manual v3.2.0
6.21. MSCP Storage The vtVAX virtual MSCP storage controller emulates the RQDX3 controller and attached disk and tape devices. Both physical and logical storage are supported for disks and tapes (see above), including up to four MSCP disk controllers (32 units each) and one MSCP tape controller (16 units).
To configure MSCP devices, first a controller is added to the configuration by right-clicking on the MSCP storage heading and selecting the desired controller from the drop-down menu (see figure, above). Next, individual devices are added by right-clicking on the controller name and selecting the desired unit from the menu. This process is repeated for all desired controllers and units. The storage device configuration parameters are described above. Logical disk container files must be present in the specified location before the emulator is started. Logical tape container files that are not found when the emulator is started will be created. The virtual MSCP tape controller has two parameters that apply to all tape units: - Type is always ‘custom’. - File Size specifies the maximum size of the container file (in MB); it is not applicable to physical tape devices. When the container file is full, it will be treated as an end-of-tape condition and a mount request for the next volume will be generated. 6.22. SCSI Storage The virtual SCSI controller allows physical or logical SCSI devices to be configured. For data migration purposes, SCSI tapes and disks from the physical VAX may be connected to the host and used on the virtual VAX system if the necessary cables and adapters can be located. We recommend against using the legacy devices as the primary storage media because of their age and the associated reliability and performance considerations. The process for configuring SCSI devices is almost identical to that described above for MSCP devices. To add a SCSI controller: right-click on SCSI storage and select the desired controller. Unlike the MSCP controller, both disks and tapes are attached to the same SCSI controllers. Logical devices defined in the SCSI configuration section are defined as disks or tapes by the file type of the container file: .vtt files are assumed to be tapes; all others are treated as disks. All SCSI devices, disk and tape, are identified with the prefix ‘pk’ in the vtServer configuration menu: the actual devices will have a prefix of DK (disks) or MK (tapes). 6.23. DSSI Storage The structure of the DSSI storage subsystem contains an extra layer between the controller and the storage unit. This middle layer is called the device and the lowest layer is called the (storage) unit (see figure, below).
Page 50
June 2018 vtServer® Reference Manual v3.2.0
The process for configuring the DSSI devices follows the same pattern as the MSCP and SCSI controllers: The following DSSI devices are supported: - Logical Disks. The storage unit is a container file within the host’s file system. - Physical Disks. The storage unit is a physical disk attached to or accessible by the host. The device is formatted using the virtual system’s file system. - Physical Tapes. Direct-attached tape device.
To add DSSI devices you select the DSSI controller, then add the DSSI device, and finally add the DSSI unit. You can select the desired storage device from the right mouse click option list. The virtual SCSI adapter has several options that can be altered: At the Device Level - Class. The MSCP allocation class (0-255). The allocation class is added to the device name as a prefix (e.g., $1$DUA0) to help create a unique device name in a cluster environment. - Host Name. Specifies the device host name (1-6 alphanumeric characters). The host name appears in some cluster management displays and is used in place of the allocation class in device names when the allocation class is 0. At the Unit Level - Media Type. Used to define a physical disk or container file as a different controller type (DU, DI, or DK). Default: DU - Write Lock. The ability to mark the volume as write-protected (enabled) or read/write (disabled). Default: disabled - Buffering. Buffering of information transfer to speed up disk/data access can be enabled or disabled. Default: disabled - Unit ID. An identifying number for the device. Default: 0 6.24. Network vtVAX supports three (3) types of Ethernet adapters:
Page 51
June 2018 vtServer® Reference Manual v3.2.0
- DEQNA/DELQA & EZ Controllers (VAX models except 7000 series, depending on the VAX hardware support)
- EX Controllers (VAX 7000-xxx series only)
The virtual network adapters have several options that can be altered: At the Device Level - Hose (VAX 7000 only, EX Controllers only). To create unique and unchanging device names, the use of allocation classes has been made available. - Slot (VAX 7000 only, EX Controllers only). - Type (non-VAX 7000, XQ Controllers only). Allows selection of root device drivers: DELQA or DEQNA. - CSR (non-VAX 7000 only). Control/Status Register (typically 6-digit address starting with “7”) - MAC address (all systems). Network Media Access Control address; only needed when certain software licenses are tied to the MAC-address of the Ethernet adapter of the system it was running on. The MAC address is entered in octet format (nn-nn-nn-nn-nn-nn); octets may be separated by a colon(:), dash (-), or period (.). At the Unit Level - Line (all systems). Right mouse click on this field and choose one of the presented network options.
Although the various hardware Ethernet adapters differed in line speed, the virtual Ethernet only delivers one speed level: as fast as possible. The virtual Ethernet adapter will utilize all the line speed it has available and, since it is a virtual Ethernet adapter, the actual line-load depends on the performance of the host system.
Page 52
June 2018 vtServer® Reference Manual v3.2.0
6.25. Serial Lines For serial line support beyond the available default serial ports (OPA0 and TTA, as supported by the VAX series), the virtual equivalent of the TX serial lines adapter (DHQ11/DHV11) is available in vtVAX. Each TX controller is configurable to support either 8 or 16 serial lines (Linecount field). A maximum of 4 virtual TX controllers (DHQ11/DHV11) are supported offering up to 64 serial lines in the vtVAX environment. To add a virtual TX controller, right mouse click on the Serial Lines field and select one from the list of available adapters; click on the adapter to add it to the configuration.
By default, the TX controller will display the current values for Linecount, CSR and Vector. Right mouse click on the Linecount to display the option of selecting a TX Controller that supports either 8 or 16 lines. Additionally, the TX controller can be modified by inserting a user-defined CSR and Vector using the following guidelines:
CSR: Control/Status Register (typically 6-digit octal address starting with “7”) Vector: Vector address (3-digit octal address)
Right mouse click on the inserted controller (e.g., TXA) to generate a selection list to begin the definition of the additional serial lines (or optionally, allow removal of the controller device). Each serial device (line) will need to be configured with a unique port number by entering the address in the field provided (examples: port number – 21005; device address - /dev/ttyS0). Default: none
6.26. Miscellaneous: Printer File The printer file is a disk file that receives output directed to the line printer interface (LPA0:) The default location of the printer file is the directory where the XML configuration file is stored. Default: none
6.27. VCB02 Stub The VCB02 stub is a pseudo-device that configures on the virtual VAX configuration but is not usable. It is provided for VAX systems that use the presence of a graphics adapter to determine whether the system boots as a workstation or non-workstation model. When this option is present, the VCB02 stub should be enabled if the vtVAX instance is replacing a VAXstation; it should be disabled if the original system is a VAX server model. Default: disabled Page 53
June 2018 vtServer® Reference Manual v3.2.0
7. Storage Management vtServer can connect various storage devices to a virtual Alpha or VAX via the configuration file: Physical disk Physical tape Logical disk Logical tape Physical disks and tapes are assigned in full to any virtual system. Logical devices are virtual storage components residing as a container file on a disk on the host system. This Storage section of vtMonitor is used to manage the host’s storage components. There are five tabs in the Storage section: - Host Storage, manage all storage accessible from this host - Fibre Channel, manage the connection of SAN storage for this host - iSCSI, connect/disconnect iSCSI storage hosts - NFS, connect/disconnect NFS storage - SMB, connect/disconnect SMB storage 7.1. Host Storage Tab The Host Storage tab is used to manage all the storage that is accessible from this host: physical disks, logical disks, Fibre-Channel SAN, NFS/SMB storage, and iSCSI. The Host Storage display is shown in the figure below. The panel on the left displays the contents of a storage component selected in the right panel. Right-click on an item in the left panel to display the available management options.
Page 54
June 2018 vtServer® Reference Manual v3.2.0
7.2. Storage Overview The panel on the right displays information about the storage elements, both physical volumes and partitions, available on the host system. Column 1 specifies the device name. Column 2 shows the device mount point name. Column 3 shows the size of the device or partition. Column 4 shows the amount of free space available (mounted devices only). Column 5 shows the device type or file system used for that device/partition. Column 6 shows the volume label. Column 7 shows the generic device name, where applicable. Columns 8-11 show additional information to help identify a device in the list. Clicking on a column heading will sort the list by the values in that column. Referring to the figure in section 4.5.1: the physical disk /dev/sdb has two partitions: the partition mounted as / is the vtServer system partition, which cannot be accessed by users; the partition mounted as /data utilizes the remainder of the physical disk. Mounted disks or partition other than / can be used to store the container files for logical devices (tapes, disks, iso files, etc.). Unmounted disks or partitions can be used as physical disks by vtAlpha or vtVAX. Right-clicking on a device will display a quick menu with the available management options, which depend on the type of storage element and its current state.
In the example above, unmounted partition /dev/sdc1 has been selected. The available options are to mount the partition or to delete the partition on the disk, leaving an unpartitioned volume. Clicking on a mounted unit displays the contents of that unit in the left panel. Selecting a physical disk (not a partition) allows copying the content of that disk to a logical disk. 7.3. Mounting/Dismounting Disks The figure above shows five mounted disks, as indicated by the existence of a mount point. Some mount points, such as /(root) are protected to prevent access by the virtual VAX and Alpha instances; the remainder can be assigned to the virtual clients in the configurations. Unmounted storage elements with a label displayed in column 6 are available to mount, as described above. The mount device dialog box allows the user to specify the mount point name; the volume label is used by default. The user may also specify that the volume will be mounted permanently, meaning it will be automatically mounted each time the host system reboots. When a mounted volume is manually dismounted, it will be removed from the permanent mount list.
Page 55
June 2018 vtServer® Reference Manual v3.2.0
7.4. Logical Device Management Selecting a mounted disk or partition with either a left- or right-click displays a list of the files and directories that it contains in the left panel. Container files for the client systems’ logical disks and tapes are listed as any other file.
The folder icon ( ) denotes a directory; the disk cylinder icon ( ) denotes a non-directory file. Clicking on the “…” directory item will move the working directory up one level in the directory tree. Right-clicking on a file or directory displays a pop-up menu with a list of the available management options for the selected item. Items marked with are compressed/zipped files that cannot be connected to a storage adapter.
Available options:
Create new directory (to group logical devices) Create a new logical device in this directory Copy an existing logical device to a new location or a new name Move a logical device to another location Rename a logical device Delete a logical device Extend a logical device (enlarging it) Compress/Decompress a logical device (ZIP/UNZIP operation) Copy logical device content to a physical disk
Page 56
June 2018 vtServer® Reference Manual v3.2.0
Example of a copy operation
The source directory and file name are shown in the gray boxes and cannot be changed. The default destination directory is the same as the source directory; the destination file name is entered by the user. The destination device and directory are selected from the right and left panels, respectively. The Rename dialog box is similar, without a target device/directory selection. 7.5. Fibre Channel Storage (SAN) vtServer connects to multiple types of SAN storage (HP MSA, EVA, 3PAR, EMC, Hitachi, VPLEX, etc.) via modern host Fibre-Channel (FC) adapters. Currently most QLogic and Emulex FC adapters are supported. vtServer makes the attached SAN storage transparent for the Alpha Operating System (OpenVMS or Tru64), allowing it to connect SAN types for which no support is included in the OpenVMS or Tru64 Operating Systems. The Fibre-Channel sub-tab shows all physical FC adapters that are installed in the vtServer Host system. vtServer allows the sharing of physical FC adapters by multiple virtual Alpha systems.
Page 57
June 2018 vtServer® Reference Manual v3.2.0
When a FC adapter is shared, all storage attached to controllers connected to the FC is also shared. If this is not desirable, such as when storage zones are required, multiple virtual FC adapters may be created and attached to one physical FC adapter. Each virtual FC adapter may be shared or not, as desired, and configured to access a subset of the physical storage. To configure a FC adapter, right click on one of the adapters to display a context menu with available options. In this example, physical FC adapter fcad3 has two virtual FC adapters assigned (fcad5 and 6). By assigning a virtual FC adapter in your SAN using the IDs of the virtual storage adapter, it is possible to restrict access to portions of the storage network to certain virtual Alpha systems (Virtual Zoning). 7.6. iSCSI The vtServer host must connect to iSCSI devices before these devices will be available in the Host Storage display. iSCSI device connections are added and deleted in the iSCSI tab.
The top section of the iSCSI screen displays the host’s iSCSI Qualified Name, which is automatically generated from the vtServer hostname and cannot be changed. The middle section of the screen displays the known iSCSI targets. Right-click on a target in this list to edit or delete it. The bottom section of the screen displays configuration details of the selected iSCSI target. These configuration items may be modified by editing the text.
Page 58
June 2018 vtServer® Reference Manual v3.2.0
7.7. NFS To use NFS, the NFS client service must be enabled from the vtServer menu on the console, or from the menu in vtMonitor. The NFS tab is used to connect and disconnect NFS storage locations to the host. After this step, subsequent management is performed using the Host Storage tab.
The NFS tab shows all NFS storage that is currently connected to the host (if any). The right mouse button opens a quick menu with the available options. Adding new NFS elements opens a pane at the bottom of the NFS tab:
The remove option is only presented when an unmounted device is selected.
Page 59
June 2018 vtServer® Reference Manual v3.2.0
7.8. SMB
To use SMB, the SMB client service must be enabled from the vtServer menu on the console, or from the menu in vtMonitor.
The SMB tab shows all SMB storage that is currently connected to the host (if any). The right mouse button opens a quick menu with the available options. After this step, subsequent management is performed using the Host Storage tab. Adding new SMB elements opens a pane at the bottom of the SMB tab:
The remove option is only presented when an unmounted device is selected.
Page 60
June 2018 vtServer® Reference Manual v3.2.0
8. Toolbox The Toolbox consists of sections (tabs) used to manage the vtServer host environment. Each section is described in detail below. Note that this section also applies for the management of vtLicense servers. Some functions only apply for vtServer management and are therefore omitted from the vtLicense GUI. 8.1. Host
Reboot Host causes the host system to be rebooted automatically. Shutdown Host will power down the host system. Both functions prompt the operator to confirm the reboot/shutdown when any virtual VAX or Alpha systems are running. After the host system is restarted, the user must refresh (F5) the browser window for vtMonitor to reconnect. Support Info creates a TGZ format archive containing host system configuration information that is downloaded to the system you are running vtMonitor from. A support info file should be created and submitted whenever reporting a problem with vtAlpha or vtVAX. Product Update is used to apply product updates and patches. See Chapter 2 for more details. Refresh updates the host information displayed in the main window of the Host tab. The left side of the window shows the host hardware configuration and release information of the vtVAX and vtAlpha products; the right side is used to review and change the host’s date and time setting. In the Host Name section, the name of the vtServer host can be altered. This local name change does not propagate to the DNS server(s); these changes must be made by the network managers. The Host Services section is used to manage the state and auto-start status of the network services (FTP, NFS, SMB, SSH and Multipath). The first column shows whether a function is running () or stopped (). The second column indicates the auto-start status of that function and determines whether that function is automatically started on host system (re)boot. Clicking any of these boxes toggles the status of the selected function. Activating SSH automatically activates the SFTP capability.
Page 61
June 2018 vtServer® Reference Manual v3.2.0
The Host Date and Time section is used to manually adjust the host system’s date, time, and time zone settings.
Page 62
June 2018 vtServer® Reference Manual v3.2.0
8.2. Network The vtServer network subsystem is used to both manage the vtServer host system and to provide network connectivity for the virtual Alpha and VAX systems. In the simplest form, there is a one-to- one association between virtual and physical network interfaces, with one additional interface used for vtServer host management. In addition, vtServer provides server logical network devices that can be used to provide additional flexibility and reliability for the network configuration. In the following list, # represents a unique sequence number that is assigned to each physical or logical device. . eth# - designates a physical Ethernet interface. A physical interface may be dedicated to either vtServer host management or a virtual network interface, connected to a virtual switch, or bonded with other physical interfaces. The latter options are described below. . avt# - designates a virtual network switch (VNS). A VNS is used to allow multiple virtual interfaces, including the vtServer host management interface, to share a single physical interface. A VNS may also be used to provide connectivity between emulation instances running on the same host without routing the traffic onto the physical network. A virtual switch can be attached to one or more physical host Ethernet interfaces. Only 1 physical interface can be active at any given time. When more than 1 eth# device is assigned to a VNS, one link is the main link; the others are for fail-over only. When multiple eth# devices are connected to a virtual switch, the potential exists for a loop to be introduced into the network. To prevent this from occurring, the Spanning Tree Protocol (STP) is activated by default. If local policy prohibits use of STP, it can be disabled; however, careful manual review of the configuration is advised to prevent the introduction of a loop that can disrupt the entire network. . mgr# - designates a vtServer host management port, which must be defined when a single physical interface is used for both the host management interface and one or more virtual network interfaces. Multiple management ports may be configured on multiple virtual switches. . bond# - designates a bonded network device. A bonded device combines multiple host Ethernet interfaces into one virtual network device that can be configured to provide various combinations of load sharing and fail-over. . VLAN – designates a virtual LAN, which can be assigned to eth and bond devices. VLANs should be defined only when they are supported by the local network environment and under the guidance of the local network support organization. . xwi0 – designates the virtual X-Windows interface used for Alpha and VAX workstation virtualizations. The eth and xwi devices are always configured; all other devices listed above are created on demand.
Page 63
June 2018 vtServer® Reference Manual v3.2.0
The configuration examples that follow show different ways the physical and logical network elements can be utilized. NOTE: Host Ethernet adapters that are connected to a virtual switch must permit promiscuous mode operation and forged transmits. When using a virtualized host system (e.g., VMware), these settings must be enabled in the hypervisor configuration.
Configuration A shows the basic approach, where one virtual Alpha interface is connected directly to a host Ethernet adapter. A VLAN should be assigned to the physical interface as shown only when required by the physical network infrastructure. Configuration B shows the use of a virtual switch to allow multiple virtual VAX and Alpha instances to share physical network interfaces. Only one physical interface, designated by the solid line, is active; additional physical interfaces, if present (designated by the broken line), are used for fail- over purposes. NOTE: In this configuration, Spanning Tree Protocol is enabled by default. Configuration C illustrates the use of a virtual switch to interconnect virtual Alpha and VAX instances on the same host without passing the traffic onto a physical network. Additional virtual network interfaces on the VAX and Alpha systems can be connected to physical interfaces to provide external network connectivity. Configuration D shows two physical network interfaces bonded into a single bond device. As in configuration A, the VLAN is optional and should be configured only when used in the local network infrastructure. Configuration E illustrates multiple virtual VAX and Alpha systems sharing a single bonded network interface using a virtual switch. Again, the VLAN is optional.
Page 64
June 2018 vtServer® Reference Manual v3.2.0
Configuration F shows the multiple virtual Alpha and VAX systems sharing a single network interface with the vtServer host management interface. The mgr0 interface is configured with an IP address (static or DHCP); no IP address is configured for the physical interfaces. The network configuration details are displayed and managed using the Network tab in the vtMonitor Toolbox. A list of the available physical and virtual network devices is displayed in the bottom portion of the Network tab screen, below the heading Virtual Network Configuration (see below). The list of network devices starts with the host adapters that are not assigned to a Virtual Network Switch. Next are the Virtual Network Switches and the host adapters (ports) that are assigned to these. The device state (up/down/standby/listening/learning) is also displayed.
Selecting a physical adapter displays the adapter configuration settings in the top portion of this screen, where these settings can be modified, if desired. Existing settings are modified by entering the new value(s) in the text boxes and pressing the Update button, which appears when a section is selected. Selecting the DHCP option replaces user-specified addresses with those returned by the DHCP server. Gateway addresses are provided for each network adapter. Checking the Default Gateway box will use the specified address as the default for adapters that do not have a gateway address explicitly specified.
Page 65
June 2018 vtServer® Reference Manual v3.2.0
The adapter status and communication settings are displayed below the address settings. The options to set the line speed and duplex are not displayed when auto negotiation is enabled. These settings can also be changed using the console interface of the emulation instance, as shown below. P00>>> set ewa0_mode ? invalid argument – valid selections: twisted-pair (10 Mb full) full-duplex (10 Mb full) aui (10Mb half) bnc (10 Mb half) fast (100 Mb half) fastfd (100 Mb full) auto-negotiate (10, 100, 1000 Mb half/full) host (determined by host) Modification to the settings made using the console interface are stored in the NVRAM of the emulated Alpha or VAX system and will override the vtServer settings. DNS server addresses are host-wide and therefore occupy their own section in this window. Up to three DNS server addresses may be defined. Incorrect settings for the gateway and DNS server addresses may result in the host system becoming unreachable. If this occurs, the vtServer (blue screen) configuration interface must be used to correct the configuration. Right-clicking on a device in the Virtual Network Configuration section displays the options available for that device, which will be a subset of the following: - Add/Delete/Connect/Disconnect Management Port - Add Ethernet to Device - Delete Virtual Network Switch - Add/Disconnect/Delete VLAN - Add/Disconnect/Delete Bond - Connect xwi0 to Device - Enable/Disable Spanning Tree Protocol
The Add Switch button creates a new Virtual Network Switch. A unique name will be assigned to the switch automatically. The Add Bond button creates a new Bond device. A unique name will be assigned automatically, starting with bond0. A bond-modus must be selected. The bond mode options are described below: balance-rr [default] This is a round-robin policy where each packet is transmitted on a different physical interface. The balanced-rr mode provides load balancing and fault tolerance. active-backup. Only one slave in the bond is active. A different slave becomes active only if the active slave fails. The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch. balance-xor. Transmit based on the selected transmit hash policy. The default policy is a simple [(source MAC address XOR'd with destination MAC address) modulo slave count]. Alternate transmit policies may be selected via the xmit_hash_policy option. Broadcast. Transmits each packet on all slave interfaces. This mode provides fault tolerance. 802.3ad dynamic link aggregation. Creates aggregation groups that share the same speed and duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad Page 66
June 2018 vtServer® Reference Manual v3.2.0
specification. Slave selection for outgoing traffic is done according to the transmit hash policy, which may be changed from the default simple XOR policy via the xmit_hash_policy option, documented below. balance-tlb adaptive transmit load balancing: channel bonding that does not require any special switch support. In tlb_dynamic_lb=1 mode; the outgoing traffic is distributed according to the current load (computed relative to the speed) on each slave. balance-alb adaptive load balancing: includes balance-tlb plus receive load balancing (rlb) for IPV4 traffic, and does not require any special switch support. The receive load balancing is achieved by ARP negotiation. The bonding driver intercepts the ARP replies sent by the local system on their way out and overwrites the source hardware address with the unique hardware address of one of the slaves in the bond such that different peers use different hardware addresses for the server. 8.3. User Accounts
The User Account tab is used to add and remove user IDs from the vtServer host and to change login passwords for these user IDs. When the tab is first selected, a list of existing user IDs is displayed. Use the quick menu to select an action to be performed. Adding and changing user records will open a pane in this window with the required data fields. The user ID ‘root’ is present on all vtServer hosts and may not be removed. The root ID is used to login to the vtServer management interface and is normally used for all management functions. Additional user IDs can be added if desired to control access to the vtMonitor interface and the network services, if enabled. 8.4. License Mgt Note: the right-hand pane is not shown when managing a vtLicense unit.
Import License loads and applies license key updates received from your vtAlpha/vtVAX supplier into the host system. This manual license update can be applied when you do not want to use the online update, which requires Internet access on the host system. You are required to enter the license key number of the key you want to update.
Page 67
June 2018 vtServer® Reference Manual v3.2.0
Export License downloads a file containing the host’s license key to your management station. This function is only needed when the information is requested by your vtAlpha/vtVAX support organization. Refresh updates the license information displayed in this panel (e.g., after a license key change). The left-hand panel of the License window displays any detected vtAlpha and vtVAX license keys. If remote license servers are defined, license keys present on the remote server(s) will be displayed in addition to those present locally. The right-hand panel of the License window is used to manage network license servers. The Enable and Disable buttons in the right-hand panel control the state of the network license server on this host. When the network license server is enabled, the content of all license keys on the host are made available to other vtServer hosts. The table displayed beneath the local network license server status shows which remote license servers are visible to this host. These network license servers may hold production licenses and/or disaster recovery licenses. The quick menu for the remote license server list is used to add or remove remote license servers. The order in which the remote license servers are polled by this host is changed by moving the entries in the list by dragging and dropping them using the mouse. The user may connect to the management console of a remote license server by selecting it from the list. A new browser window or tab will be created. The user will be required to authenticate on the remote system by supplying a valid username and password. 8.5. Backup
Import (vtServer only) uploads a specified configuration archive, created with the ‘export configuration’ function of the configuration list quick menu, from the management station you are working on to the host system. Configurations loaded from the imported archive will replace existing configurations on the host with the same name. Backup creates an archive (.tgz) of all the vtServer/vtLicense system settings, configurations, and log files which is downloaded to the vtMonitor workstation. Restore restores the vtServer/vtLicense system settings and configurations saved with the Backup function. The Backup and Restore functions can be used to duplicate a vtServer host system or to restore a host after a clean install of vtServer. When duplicating a host system configuration, be aware that fixed IP addresses, such as those for management interfaces, are copied as well; these addresses must be changed before the new host system is rebooted on the same network as the original host to prevent duplicate addresses from appearing on the network. The Backup and Restore functions do not save Alpha or VAX system data, which must be saved using normal VMS or Tru64 backup procedures.
Page 68
June 2018 vtServer® Reference Manual v3.2.0
8.6. Support
Support Info creates a .tgz file containing information used to diagnose host system and emulator problems. The archive is automatically downloaded to the workstation you are running vtMonitor on. A support information file should be created and submitted to your support provider any time you are reporting a problem with vtServer, vtLicense, vtAlpha or vtVAX. Open Link establishes a data link to the AVT support center. This link allows the support engineers to connect to your host system to investigate and diagnose problems. This feature should be used only when directed to do so by your support provider. When a support link has been established a Close Link button will appear so that the user can disconnect the link at any time.
Page 69
June 2018 vtServer® Reference Manual v3.2.0
9. Firewall (vtLicense only) Configure the firewall for vtLicense. By default, port 80 and 443 (HTTP and HTTPS) on the local unit are enabled. Other ports can be added if so desired. IP-address 0 means localhost. Right-mouse-button click on the list allows to add/delete rules. Changes are not instant and need to be stored via the SAVE button. Refresh renews the screen content. Import/Export allow to exchange prepared settings between vtLicense boxes. Enable/Disable switches the Firewall function on or off. Default is Disabled.
Page 70
June 2018 vtServer® Reference Manual v3.2.0
10. Special Operations
In this section, you will find information on various features that are not documented elsewhere in this manual.
10.1. vtAlpha/vtVAX License in a Network.
10.1.1. Functional Description vtAlpha and vtVAX license information is stored on a special license key that fits into a USB slot of the host computer or vtLicense server. The virtual Alpha and VAX instances check for the presence of a valid license when started and at periodic intervals while the virtualization is running. A valid license appropriate for the emulated system must be detected for the emulator to start. If the license is not found during one of the periodic checks an alert will be issued (see section 0) and the emulation will continue executing for up to 16 hours before execution is terminated. Each license key may contain primary or backup licenses for one or more vtAlpha and vtVAX instances. The type and number of virtual systems that may execute simultaneously is determined by the available licenses. When primary and backup licenses are present, the primary licenses will be allocated first, then the backup licenses. In the simplest case, the license key is inserted in a USB port on the vtServer host system. There are several circumstances under which the license key must be located on a system other than the host using licenses present on that device: - There is no physical access to the host. - The host has no available USB slots (e.g., a blade system or virtual host). - The host is a virtualized system that may be migrated to other physical servers. - Fault tolerant configurations that provide redundancy for the host servers and/or license dongles. - Licenses for multiple host systems are stored on a single license key. The vtAlpha/vtVAX licensing mechanism supports these options by the ability to access license keys installed on remote license servers that are network-accessible to the vtServer host. The remote license server may be another vtServer host or a vtLicense server, which is a dedicated network appliance with USB ports for the license keys. The diagram below shows the license key inserted in a remote license server. The IP address of the remote license server is defined on the vtServer host (see section 10.1.2).
Page 71
June 2018 vtServer® Reference Manual v3.2.0
The diagram below shows a similar configuration with multiple license servers to provide higher availability.
Each license server may serve licenses for multiple vtServer host systems. When using a virtual machine fail-over mechanism like VMware’s vMotion, the deployment of multiple vtLicense servers in a network in combination with production and disaster recovery licenses allows you to create a very disaster resilient (DR) virtual Alpha/VAX installation.
10.1.2. Network License Installation Instructions To use the network-based license setup, identify the systems to be used as remote license servers and their IP addresses. The remote servers may be a vtLicense appliance or another vtServer host. The remote server must be accessible via IP from the vtServer host utilizing the server. Step 1. Setup the license server computer 1. Another vtServer host On the vtServer host system hosting the license dongles: login to the console; select the configuration menu option; select license server; then select the option enable local system as license server from the options list. This activates the license server task, which runs in the background. 2. vtLicense Obtain the product, assign it a network address and connect it to the network.
Step 2: Point the vtServer host to the network server Configuration of remote license servers is performed from the vtServer (blue screen) configuration menus using the host system console. Select configuration > license server > remote from the menus and enter the IP address/DNS name of the remote license server in the dialog box.
Multiple remote license servers may be defined to provide increased redundancy and reliability. A secondary license key may be a full license or a disaster recovery key with a limited run-time to survive temporary unavailability of the primary license key.
Page 72
June 2018 vtServer® Reference Manual v3.2.0
10.2. X-Windows Terminal Access on vtAlpha/vtVAX Host (workstation).
10.2.1. General vtAlpha and vtVAX can be used to replace AlphaStation and VAXstation workstations. Instead of emulating the workstation video adapter, vtServer implements an X-Windows server that interfaces to the Alpha or VAX client using an internal network interface (xwi0). The host systems video display is used as the workstation monitor. One notable difference between the physical and virtual workstation configurations is that the host keyboard and monitor are not used as the guest system console interface. The default IP address for xwi0 is 10.143.0.1, but this can be configured to another address when so desired. EWB0 (in this example) should have an address in the same subnet (e.g., 10.143.0.2).
The default X-server security settings restrict access to the server to localhost (127.0.0.1), 10.143.0.1 and 10.143.0.2; the vtServer configuration menu (main menu → graphics → security) may be used to add access from other IP addresses, as needed.
Configuration of the host video display devices is performed using the vtServer configuration menu (main menu → graphics → display). The monitor configuration screen is shown in the diagram to the right. The position of the monitor(s) can be changed by clicking on one of the monitor window icons (LVDS-1 or VGA-1 in this example) and dragging it to the correct position. Right- click on a monitor window icon to display options to enable/disable the selected monitor or to change the display resolution. Apply applies the settings without permanently saving them. When you are satisfied, select the Save option, then click on the ‘X’ button in the upper right corner of the window to close it. If you want to automatically start the system as a workstation, enable the emulator autostart for the instance in the user interface, enable autoboot for the operation system in the SRM-console by entering a default boot device and setting AUTO_ACTION to RESTART, and set the X-display to auto start in the vtServer console (main menu → graphics → autostart).
10.2.2. Single Network Interface Systems. The following procedure is required to configure graphics access on VAX systems that have only one network interface. For detailed instructions on configuring these emulated workstations for graphics use, please refer the Technical Note vtVAX Bare Metal Graphics Configuration for Workstations with One Network Interface, which may be downloaded from the Vere Technologies web site (http://vax-alpha-emulation.com/doc). Page 73
June 2018 vtServer® Reference Manual v3.2.0
The procedure provided in the previous section for configuring an emulated VAX workstation for graphics use requires the use of two virtual network interfaces on the VAX system: one for the general network traffic, and one dedicated to the X-Windows server. The VAXstation 4000 model 90 supports only one network adapter. To configure the graphics on this system a virtual switch is used to allow both the primary network and the X-Windows server to use the single virtual adapter. For the purposes of this documentation, ‘avt0’ is used to designate the virtual switch used for the graphics configuration, and ‘eth1’ is the host network interface assigned to the virtual VAX. The actual device names may vary depending on your configuration. 1) Create a new virtual switch to use exclusively for the X-Windows server. 2) Add network interfaces xwi0 and eth1 to switch avt0. 3) Configure xwi0 with an IP network address and mask in the same subnet as the VAX system’s IP address. 4) Using the vtServer console interface or an SSH session to the vtServer host, add the IP address assigned to xwi0 to the X-display authorization list (vtServer > Graphics > Security). 5) In the VAXstation configuration, connect the VAX virtual network adapter EZA0 to switch avt0. 6) Boot the virtual VAX system and configure DECwindows as described in one of the following settings, then reboot the operating system. 7) Enable the X-server from the vtServer console or SSH session (vtServer > Graphics). The same menu is used to configure the X-server to auto-start, if desired.
10.2.3. DECwindows Setup on VMS
The following OpenVMS setup allows the virtual workstation to come up with the original DECwindows desktop.
Configure TCP/IP with an additional interface at address 10.143.0.2/24, and verify that TCP/IP is started in the system startup.
1. Create the file SYS$SPECIFIC:[SYSMGR]DECW$DEVICE.COM with the following content:
$ decw$device == "vtServer"
(Replace vtServer with the IP host name or address of the vtServer host.)
2. Create the file SYS$SPECIFIC:[SYSMGR]DECW$PRIVATE_APPS_SETUP.COM with the following content:
$ define/nolog/system decw$default_transport tcpip $ decw$appsnode == "10.143.0.1"
(If the default IP address for xwi0 is changed, replace 10.143.0.1 with the xwi0 address.)
The following example shows how to create a display for a single X-Windows application:
$ set display/create/transport=tcpip/node=10.143.0.1 $ run sys$system:decw$clock
Page 74
June 2018 vtServer® Reference Manual v3.2.0
10.2.4. DECwindows Setup on Tru64 [vtAlpha only]
The following setup allows the system to come up with the original DECwindows desktop.
Add the following line to /usr/dt/config/Xservers: 10.143.0.1:0 foreign
The display can be referenced by setting the variable DISPLAY to 10.143.0.1:0.0 (When the IP address of the br0 interface is customized, adjust the addresses above accordingly).
10.3. Improving I/O Performance
Disk performance of the virtual Alpha and VAX systems can be increased significantly by enabling the read and write caching options.
Care must be taken that the caches are enabled only on storage elements that are not shared by another host to prevent data corruption or reading stale data.
Page 75
June 2018 vtServer® Reference Manual v3.2.0
10.4. Transferring Files to/from the vtServer Host The vtServer installation includes the Samba (SMB) server, which can be used to exchange files between the vtServer host and systems running Microsoft Windows or Linux.
By default, the SMB server is disabled; the following procedure shows how to enable it either temporarily (until it is disabled, or the host is rebooted) or permanently.
Login on the vtServer host system console (blue screen interface). Select the configuration option from the main menu. Select smb from the next menu. If the server status is disabled, select the Start option to enable it immediately. If auto-boot is disabled, select the Auto-boot option to enable it each time the vtServer host is booted, if desired. Note that this will not start the server until the next host boot. Note the IP address or host system name of this vtAlpha host for later use. When smb is running, exit this menu structure.
The next two sections show how to access the vtServer host from a Windows or Linux client after the SMB server has been started.
10.4.1. Windows Client To access the vtServer host from a system running Microsoft Windows, open a Windows Explorer window and specify the vtServer host’s IP address or host name (if it is in DNS) in the following format:: \\IP-address or \\host-name. After entering your username and password, a list of the accessible directories will be displayed. Select the desired directory and then transfer files using drag-and-drop, as you would when transferring files on your Windows system.
10.4.2. Linux Client Temporary Mounts (from the Command Line) - Your mapped drives (network drives) can be mounted either temporarily or permanently. We start with temporary mounts. Permanent mounts are detailed below. Temporary Mounts: Unsecured/guest shares (no credentials required) - Shares that can be accessed without credentials (i.e., no username/password), for example, share- level shares in Windows or world-readable Samba Linux shares can be mounted from the command line in a root console/terminal as follows: mount -t cifs -o guest //192.168.44.100/share /path_to/mount Notes: (1) the only option here is -o guest (2) the network name of the server may be used instead of the IP address, as follows: mount -t cifs -o guest //server/share /path_to/mount
10.5. TapeMGR [for managing logical tapes]
Logical tapes can be used to virtualize a physical tape drive and use tape container files instead of physical tape cartridges. By default, a logical tape container file will grow as data is written to it.
Page 76
June 2018 vtServer® Reference Manual v3.2.0
When an unload command is sent to the virtual tape drive, the tape will be disconnected from the emulator and the container file may be copied or moved. This applies to the vtAlpha as well as the vtVAX. On vtAlpha and vtVAX, you also have the option to set the “Autoload” option in the emulator configuration and the option to manipulate it via the TapeMGR tool. When this parameter is enabled, the tape will be loaded automatically when a VMS MOUNT or INITIALIZE command is executed. When manual control of tape loading and unloading from the VMS system is desired, set the Autoload parameter to off and use the TAPEMGR utility to control the tapes. If a non-existent container file name is provided to the TAPEMGR LOAD command, a new container file will be created. To use the TAPEMGR utility, the TAPEMGR driver must be installed on the OpenVMS system. This utility is provided on the vttools_alpha_vms.vdisk and vttools_vax_vms.vdisk (located in /tools). The following procedures are used install the TAPEMGR driver and utility:
Assign the appropriate vttools disk to a logical disk in the emulation instance.
In this vtAlpha example we use SCSI disk DKA100, issue the commands below:
$ mount dka100: vttools %MOUNT-I-MOUNTED, VTTOOLS mounted on _VMS84$DKA100: $ product install /source=dka100:[tapemgr010] * Performing product kit validation of signed kits ... %PCSI-I-CANNOTVAL, cannot validate DKA100:[TAPEMGR010]AVT-AXPVMS-TAPEMGR-V0100--1.PCSI;4 -PCSI-I-NOTSIGNED, product kit is not signed and therefore has no manifest file The following product has been selected: AVT AXPVMS TAPEMGR V1.0 Layered Product [Installed] Do you want to continue? [YES]
And a vtVAX installation example:
$ @sys$update:vmsinstal tapemgr DKA200:[TAPEMGR]
OpenVMS VAX Software Product Installation Procedure V6.2
It is 29-JUL-2017 at 01:44. Enter a question mark (?) at any time for help. * Are you satisfied with the backup of your system disk [YES]?
The following products will be processed:
TAPEMGR V1.0 Beginning installation of TAPEMGR V1.0 at 01:44 %VMSINSTAL-I-RESTORE, Restoring product save set A ... Installing the TAPEMGR Utility for vtVAX %VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories... Installation of TAPEMGR V1.0 completed at 01:44
VMSINSTAL procedure done at 01:44
There may be slight differences between the vtAlpha and vtVAX versions of TapeMGR. One of the differences is that the tape container extension “.vtt” or “.vtape” on vtVAX is mandatory, where on vtAlpha this is not. Read the TapeMGR help for the possibilities and specifics on each platform. n.b. As of vtServer version 3.2 the vtVAX also has the option to set the format of the tape with the /format qualifier (which the vtAlpha already had). Possible values are, mtd, vtt, vtape
Page 77
June 2018 vtServer® Reference Manual v3.2.0
Help for the TAPEMGR utility may be obtained using the command TAPEMGR HELP.
An example on vtAlpha
$ tapemgr help
TAPEMGR The vtAlpha emulator allows several parameters to be specified for logical tape devices. The TAPEMGR utility can be used to create, delete or change container files, and to select the format used to read or write these files.
The utility needs OPER and CMKRNL privileges (except for the HELP and VERSION commands).
Additional information available
Author CREATE DELETE LOAD UNLOAD SET SHOW VERSION HELP
TAPEMGR Subtopic?
The TapeMGR utility for example will allow you to load and unload any tape container file available on the host.
The TAPEMGR SHOW command displays the name of the tape container file for the device, the tape format, the maximum size of the tape file, and the tape load status.
$ tapemgr show mka400 %TAPEMGR-I-INFO, _MKA400: file=/DiskImages/MKA400.vtape format=default maximumsize=unlimited autoload=yes status=loaded $ tapemgr load mka400: "/DiskImages/test.vtape" $ tapemgr show mka400: %TAPEMGR-I-INFO, _MKA400: file=/DiskImages/test.vtape format=default maximumsize=unlimited autoload=yes status=loaded $
Page 78
June 2018 vtServer® Reference Manual v3.2.0
10.6. Eco App [vtAlpha only] Normally the virtual Alpha host system emulation CPU(s) run at 100% utilization, even when the emulated Alpha CPU is idle, which increases power consumption and heat generation, which can result in premature CPU failures. To address this problem, we developed the Eco App (Energy Conservation Application). Eco App detects when the guest system CPU(s) are idle and allows the host to idle the corresponding physical CPUs. In typical applications this can result in power consumption reduction of up to 25%. For OpenVMS, Eco App is supplied as a program that must be installed on the guest system (see instructions below); for Tru64 systems, Eco App is a function provided as a console option that must be enabled before use. Now Eco App is available for Tru64 V5 only; versions for Tru64 V3 and V4 are in development.
10.6.1. Installing the Eco App for OpenVMS This Eco App driver for OpenVMS can be found on the vttools virtual disk (/tools/vttools_alpha_vms.vdisk). Create a logical disk in your virtual Alpha configuration and assign the vttools virtual disk as the device location. The write lock attribute should be enabled to prevent inadvertent modification of the vttools disk. The following example assumes that DKA100 is the vttools logical disk. $ mount/nowrite dka100: vttools %MOUNT-I-MOUNTED, VTTOOLS mounted on _VMS84$DKA100: $ product install /source=dka100:[ecoapp0101] *
Performing product kit validation of signed kits: %PCSI-I-CANNOTVAL, cannot validate DKA100:[ECOAPP0101]AVT-AXPVMS-ECOAPP-V0101--1.PCSI;1 -PCSI-I-NOTSIGNED, product kit is not signed and therefore has no manifest file
The following product has been selected: AVT AXPVMS ECOAPP V1.1 Layered Product [Installed]
Do you want to continue? [YES]
By default it will be loaded on startup of VMS, but it can be unloaded or loaded manually. Eco App has 3 commands: LOAD , UNLOAD and STATISTICS Statistics will show the percent of the time the CPUs have been idle: $ ecoapp stat ECOAPP started at 26-JUN-2013 12:41:58.85 (load at boot enabled) ECOAPP Uptime: 0 00:23:02.91
CPU idle count idle time idle ------0 1318642 0 00:22:35.97 99% 1 1391681 0 00:22:49.85 100%
Total system idle percentage since ECOAPP start: 99% $
Page 79
June 2018 vtServer® Reference Manual v3.2.0
10.6.2. Activating the Eco App for Tru64 v5 On systems running Tru64 V5, the Eco App is enabled using the SRM console command set ecoapp 1 before booting Tru64. To disable Eco App, use the command set ecoapp 0 then reboot the system. 10.7. vtSID Utility [vtVAX only] vtSID is a utility used with vtVAX when there is a requirement to match the VAX hardware System Identification (SID) of the physical VAX system being replaced. The vtSID components are provided on the vttools virtual disk that is provided in the /tools directory of the vtServer distribution. The vttools disk is mounted on the virtual VAX system and the files are copied to the OpenVMS system disk. Installation of vtSID 1. Add a new virtual disk to a vtVAX instance. In this example we will identify this disk as DUB0. 2. Configure DUB0 as a logical disk using container file /tools/vttools_vax_vms.vdisk. 3. Login to VMS with userid SYSTEM. 4. Mount the “vttools_vax_vms.vdisk” virtual disk.
MOUNT DUB0: vttools 5. Go to the vtSID directory and start VMSinstal
$ set def DUB0:[VTSID] $ @sys$update:vmsinstal vtsid010
OpenVMS VAX Software Product Installation Procedure V6.2
It is 29-JUL-2017 at 01:57. Enter a question mark (?) at any time for help. * Are you satisfied with the backup of your system disk [YES]? * Where will the distribution volumes be mounted: DUB0:[VTSID] * Enter installation options you wish to use (none): The following products will be processed: VTSID V1.0 Beginning installation of VTSID V1.0 at 01:58 %VMSINSTAL-I-RESTORE, Restoring product save set A ... Installing the vtSID Utility for vtVAX %VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories... Installation of VTSID V1.0 completed at 01:58
VMSINSTAL procedure done at 01:58
Using vtSID 6. Invoke the command procedure sys$manager:SID.com, and record the values displayed. 7. Edit SYS$SPECIFIC:[SYSMGR]VTSID.COM and replace the placeholder values in the VTSID SET command with those displayed in the previous step. 8. Manually invoke VTSID.COM to set the SID value. The procedure will display the SID before and after the change. Page 80
June 2018 vtServer® Reference Manual v3.2.0
9. Edit the site-specific system startup procedure (SYSTARTUP_VMS.COM or SYSTARTUP_V5.COM) and add a command to invoke VTSID.COM before the startup procedures for any applications that use the SID value for license validation. 10. Reboot VMS to invoke the full startup.
NOTE: The vtVAX SID is modified with vtSID; therefore, it must be reset before the system is shut down or the system may crash during shutdown and not auto-reboot. If vtSID is used, the following commands should be placed in the site-specific shutdown procedure (SYSHUTDWN.COM) and this procedure should always be invoked when the system is shut down. SET COMMAND SYS$MANAGER:VTSID VTSID RESET VTSID LIST/TYPE=ACTIVE
Page 81
June 2018 vtServer® Reference Manual v3.2.0
vtSID Commands VMS help command HELP @VTUTILS
1. LIST - Displays supported hardware models/configurations.
o /TYPE=MODELS (default) Request listing of VAX HW_Models supported by this specific VMS version and their descriptions. Model number is in hexadecimal notation.
o /TYPE=DEFAULT Displays system default values for SID/XSID/HWMODEL and CPUs.
o /TYPE=ACTIVE Displays current system values for SID/XSID/HWMODEL and CPUs.
2. SET - Set values for, SID/XSID/HWMODEL and CPUs.
o /SID=sid_value Specifies the SID value in hexadecimal.
o /XSID=xsid_value Specifies the XSID value in hexadecimal.
o /MODEL=model_number Specifies the model number in hexadecimal.
o /CPUCNT=n Specifies the number of CPUs configured under VMS.
o /CPUAVL=n Specifies the number of CPUs available to VMS.
3. RESET - Resets parameters to their default values.
When the SID is modified with vtSID, the VTSID RESET command should be invoked before or during the system shutdown. If this is not done, the system may crash or fail to auto-restart.
Page 82
June 2018 vtServer® Reference Manual v3.2.0
10.8. Installing vtServer in a Hypervisor
10.8.1. Symmetric Multiprocessing (SMP)
When running on multiprocessor configurations, OpenVMS performs frequent checks to ensure that all processors are functioning and that there are no synchronization deadlocks. If abnormal conditions are detected, the system will crash with a CPUSANITY or CPUSPINWAIT bugcheck. When an emulated multiprocessor Alpha or VAX system is running on a virtual host, certain events, most notably a host migration (e.g., using VMware vMotion), can cause the emulator execution to stall long enough for the SMP sanity timers to expire when set to their default values. To reduce the risk of OpenVMS bugchecking in these situations, we recommend that the following SYSGEN parameter changes be made: SMP_SPINWAIT – increase from 100000 (1 second) to a value between 3000000 (30 seconds) and 6000000 (60 seconds) SMP_SANITY_CNT – increase from 300 (3 seconds) to a value between 3000 (30 seconds) and 6000 (60 seconds)
These changes should be added to SYS$SYSTEM:MODPARAMS.DAT, and then AUTOGEN should be run so they will take effect the next time the system is restarted.
Page 83
June 2018 vtServer® Reference Manual v3.2.0
10.9. Security Settings vtServer is an integrated solution with its own x86 operating system kernel. To maximize stability, users do not have command line access to the vtServer host and the vtServer host software does not download or apply security updates on its own. All updates and changes are integrated and distributed with the product distribution and updates. By default, only the following network ports are open:
80 HTTP
443 HTTPS
22350 vtAlpha/vtVAX license
The following ports are used by services that may be enabled by the system administrator using the vtServer management interface (blue screen). See chapter 3 of this manual for details.
21 FTP
22 SSH
139/445 SMB (files sharing)
Additional TCP/IP ports may be defined in the virtual Alpha and VAX configurations to provide access to virtual consoles (e.g., OPA0, COM2) and serial ports.
10.10. Installing Serial Line Drivers in OpenVMS Boot VMS with disk /tools/vttools_alpha_vms.vdisk connected to DKA100.
$ mount dka100: vttools %MOUNT-I-WRITELOCK, volume is write locked %MOUNT-I-MOUNTED, VTTOOLS mounted on _VMS84$DKA100: $
$ prod install * /source=dka100:[DIGIBOARD]
1 - DIGI AXPVMS DGDRIVER D1.3-0 Layered Product 2 - DIGI AXPVMS DGDRIVER_7 D1.6-0 Layered Product 3 - DIGI AXPVMS DGDRIVER_8 D1.6-0 Layered Product 4 - All products listed above ? - Help E - Exit
Page 84
June 2018 vtServer® Reference Manual v3.2.0
Choose one or more items from the menu: (1 for VMS6.x, 2 for VMS 7.x and 3 for VMS8.x)
Performing product kit validation of signed kits ... %PCSI-I-CANNOTVAL, cannot validate DKA100:[000000]DIGI-AXPVMS-DGDRIVER_8-D0106-0- 1.PCSI;1 -PCSI-I-NOTSIGNED, product kit is not signed and therefore has no manifest file
The following product has been selected: DIGI AXPVMS DGDRIVER_8 D1.6-0 Layered Product
Do you want to continue? [YES]
Configuration phase starting ...
You will be asked to choose options, if any, for each selected product and for any products that may be installed to satisfy software dependency requirements.
Configuring DIGI AXPVMS DGDRIVER_8 D1.6-0: Digi AccelePort Device Driver for VMS 8.x
@ Digi International 1995. All rights reserved.
Digi International
Do you want the defaults for all options? [YES]
The /HELP option is required; if you didn't use it, do not continue.
Do you want to continue? [YES]
Do you want to review the options? [NO]
Execution phase starting ...
The following product will be installed to destination: DIGI AXPVMS DGDRIVER_8 D1.6-0 DISK$ALPHASYS:[VMS$COMMON.]
Portion done: 0%...10%...20%...30%...40%...50%...60%...80%...90%...100%
The following product has been installed: DIGI AXPVMS DGDRIVER_8 D1.6-0 Layered Product
DIGI AXPVMS DGDRIVER_8 D1.6-0: Digi AccelePort Device Driver for VMS 8.x
Post Installation Procedure
Users of this product require the following process resource limits: BYTLM minimum 45000
This product requires the following SYSGEN parameters: MAXBUF minimum 45000
Insert the following lines in SYS$MANAGER:SYSTARTUP_VMS.COM:
$! DON'T FORGET TO REMOVE THE ! FROM THE LINE BELOW $! @DIGI$DRIVER:DIGI_INSTALL_EPCA.COM
$
Page 85
June 2018 vtServer® Reference Manual v3.2.0
Make sure BYTLM and MAXBUF are set to a minimum of 45000 on your system.
Run the Digi Setup to configure the installed PCI PBXDA's (AccelePort Xr 920 PCI).
$ SYS$COMMON:[DGDRIVER]DG_SETUP.COM
¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ How many adapters do you wish to install? ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ Please enter a number between 1 and 7:1 ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
Choose number of adapters: 1.
When asked for type of Adapter choose: A) AccelePort Xr 920 PCI.
+------+ ¦ C/X - EPC - Xem - Xr - Xr 920 Configuration Utility version 1.6.0 ¦ ¦ Copyright (c) 1998, Digi International Inc. ¦ +------+ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦+------Adapter Selection ------+¦ ¦¦ Configuring adapter 1. ¦¦ ¦¦ ¦¦ ¦¦ Supported ISA Adapters: ¦¦ ¦¦ 1) AccelePort Xr ISA 2) AccelePort Xr 920 ISA ¦¦ ¦¦ 3) AccelePort Xem ISA 4) AccelePort C/X ISA ¦¦ ¦¦ 5) AccelePort EPC/X ISA ¦¦ ¦¦ Supported EISA Adapters ¦¦ ¦¦ 6) AccelePort Xem EISA 7) AccelePort C/X EISA ¦¦ ¦¦ 8) AccelePort EPC/X EISA ¦¦ ¦¦ Supported PCI Adapters ¦¦ ¦¦ 9) AccelePort Xr PCI A) AccelePort Xr 920 PCI ¦¦ ¦¦ B) AccelePort Xem PCI C) AccelePort C/X PCI ¦¦ ¦¦ D) AccelePort EPC/X PCI ¦¦ ¦¦ ¦¦ ¦¦ What type is adapter 1? A ¦¦ ¦¦ ¦¦ ¦+------+¦
Chose 0 to select the adapter.
+------+ ¦ C/X - EPC - Xem - Xr - Xr 920 Configuration Utility version 1.6.0 ¦ ¦ Copyright (c) 1998, Digi International Inc. ¦ +------+ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦+------Adapter Selection and Configuration ------+¦ ¦¦ Configuring adapter 1. ¦¦ ¦¦ Adapter type is AccelePort Xr 920 PCI Adapter. ¦¦ ¦+------PCI Adapter Selection ------¦¦ ¦¦ Please select a node number from one of the ones listed below: ¦¦ ¦¦ ¦¦ ¦¦ 0) 0 (Adapter 2, Bus 0, Slot 0, Func 0) -- Digi AccelePort Xr 920 ¦¦ ¦¦ 1) Exit without making a choice ¦¦ ¦¦ ¦¦ ¦¦ Enter the selection for adapter 1: 0 ¦¦ ¦+------¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦+------+¦
Accept the configuration. Page 86
June 2018 vtServer® Reference Manual v3.2.0
+------+ ¦ C/X - EPC - Xem - Xr - Xr 920 Configuration Utility version 1.6.0 ¦ ¦ Copyright (c) 1998, Digi International Inc. ¦ +------+ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦+------Adapter Selection and Configuration ------+¦ ¦¦ You have selected the following configuration for adapter 1: ¦¦ ¦¦ ¦¦ ¦¦ Adapter Type: AccelePort Xr 920 PCI Adapter. ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ Module Port Numbers ¦¦ ¦¦ ------¦¦ ¦¦ 1 0 - 7 ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ Is this configuration acceptable (y or n)? Y ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦+------+¦
Answer the other questions and finally hit Enter to complete.
+------+ ¦ C/X - EPC - Xem - Xr - Xr 920 Configuration Utility version 1.6.0 ¦ ¦ Copyright (c) 1998, Digi International Inc. ¦ +------+ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦+------Message ------+¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ Configuration Complete ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ Press ANY key to continue ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦+------+¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
Driver will be built
Linking the VMS configuration image... Linking the driver image... Installation complete. $
To finish your setup and automatically start the driver on VMS boot, add the following lines to SYS$MANAGER:SYSTARTUP_VMS.COM :
$ @SYS$COMMON:[DGDRIVER]MAKE_DIGI_LOGICAL.COM $ @DIGI$DRIVER:DIGI_INSTALL_EPCA.COM
Page 87
June 2018 vtServer® Reference Manual v3.2.0
After a reboot of VMS the TX devices will be online; if they are not online, make sure at least one of the serial ports is configured in vtAlpha (assigned to either a physical port or a virtual telnet socket). 10.11. Boot from Fibre Channel (vtAlpha only) If OpenVMS is used then the use of wwidmgr is not needed. Since device list may become large with Fibre Channel configurations the console will now allow a matching device name to be given for the 'show device' command: P00>>> show device fga0.0.0.0.1 FGA0 KGPSA 1000-0000-c92b-116c gga998.10.0.0.1 GGA998 HP MSA CONTROLLER 7.20 sg58 dga100.10.0.0.1 DGA100 HP MSA VOLUME 7.20 sg59 dga101.10.0.0.1 DGA101 HP MSA VOLUME 7.20 sg60 dga102.10.0.0.1 DGA102 HP MSA VOLUME 7.20 sg61 dga103.10.0.0.1 DGA103 HP MSA VOLUME 7.20 sg62 dga104.10.0.0.1 DGA104 HP MSA VOLUME 7.20 sg63 dga105.10.0.0.1 DGA105 HP MSA VOLUME 7.20 sg64 dga106.10.0.0.1 DGA106 HP MSA VOLUME 7.20 sg65 gga999.10.1.0.1 GGA999 HP MSA CONTROLLER 7.20 sg66 dga100.10.1.0.1 DGA100 HP MSA VOLUME 7.20 sg67 dga101.10.1.0.1 DGA101 HP MSA VOLUME 7.20 sg68 dga102.10.1.0.1 DGA102 HP MSA VOLUME 7.20 sg69 dga103.10.1.0.1 DGA103 HP MSA VOLUME 7.20 sg70 dga104.10.1.0.1 DGA104 HP MSA VOLUME 7.20 sg71 dga105.10.1.0.1 DGA105 HP MSA VOLUME 7.20 sg72 dga106.10.1.0.1 DGA106 HP MSA VOLUME 7.20 sg73 gga1000.10.2.0.1 GGA1000 DEC HSG80CCL V88F sg74 dga1.10.2.0.1 DGA1 DEC HSG80 V88F sg75 dga2.10.2.0.1 DGA2 DEC HSG80 V88F sg76 gga1000.10.3.0.1 GGA1000 DEC HSG80CCL V88F sg77 dga1.10.3.0.1 DGA1 DEC HSG80 V88F sg78 dga2.10.3.0.1 DGA2 DEC HSG80 V88F sg79 gga1000.10.4.0.1 GGA1000 DEC HSG80CCL V88F sg80 dga1.10.4.0.1 DGA1 DEC HSG80 V88F sg81 dga2.10.4.0.1 DGA2 DEC HSG80 V88F sg82 gga1000.10.5.0.1 GGA1000 DEC HSG80CCL V88F sg83 dga1.10.5.0.1 DGA1 DEC HSG80 V88F sg84 dga2.10.5.0.1 DGA2 DEC HSG80 V88F sg85 fgb0.0.0.1.1 FGB0 KGPSA 1000-0000-c93a-389c gga998.8.0.1.1 GGA998 HP MSA CONTROLLER 7.20 sg2 dga100.8.0.1.1 DGA100 HP MSA VOLUME 7.20 sg3 dga101.8.0.1.1 DGA101 HP MSA VOLUME 7.20 sg4 dga102.8.0.1.1 DGA102 HP MSA VOLUME 7.20 sg5 dga103.8.0.1.1 DGA103 HP MSA VOLUME 7.20 sg6 dga104.8.0.1.1 DGA104 HP MSA VOLUME 7.20 sg7 dga105.8.0.1.1 DGA105 HP MSA VOLUME 7.20 sg8 dga106.8.0.1.1 DGA106 HP MSA VOLUME 7.20 sg9 gga999.8.1.1.1 GGA999 HP MSA CONTROLLER 7.20 sg10 dga100.8.1.1.1 DGA100 HP MSA VOLUME 7.20 sg11 dga101.8.1.1.1 DGA101 HP MSA VOLUME 7.20 sg12 dga102.8.1.1.1 DGA102 HP MSA VOLUME 7.20 sg13 dga103.8.1.1.1 DGA103 HP MSA VOLUME 7.20 sg14 dga104.8.1.1.1 DGA104 HP MSA VOLUME 7.20 sg15 dga105.8.1.1.1 DGA105 HP MSA VOLUME 7.20 sg16 dga106.8.1.1.1 DGA106 HP MSA VOLUME 7.20 sg17 gga1000.8.2.1.1 GGA1000 DEC HSG80CCL V88F sg18 dga1.8.2.1.1 DGA1 DEC HSG80 V88F sg19 dga2.8.2.1.1 DGA2 DEC HSG80 V88F sg20 gga1000.8.3.1.1 GGA1000 DEC HSG80CCL V88F sg21
Page 88
June 2018 vtServer® Reference Manual v3.2.0
dga1.8.3.1.1 DGA1 DEC HSG80 V88F sg22 dga2.8.3.1.1 DGA2 DEC HSG80 V88F sg23 gga1000.8.4.1.1 GGA1000 DEC HSG80CCL V88F sg24 dga1.8.4.1.1 DGA1 DEC HSG80 V88F sg25 dga2.8.4.1.1 DGA2 DEC HSG80 V88F sg26 gga1000.8.5.1.1 GGA1000 DEC HSG80CCL V88F sg27 dga1.8.5.1.1 DGA1 DEC HSG80 V88F sg28 dga2.8.5.1.1 DGA2 DEC HSG80 V88F sg29 fgc0.0.0.2.1 FGC0 KGPSA 2100-00e0-8b1c-d44a gga1000.9.0.2.1 GGA1000 DEC HSG80CCL V88F sg30 dga1.9.0.2.1 DGA1 DEC HSG80 V88F sg31 dga2.9.0.2.1 DGA2 DEC HSG80 V88F sg32 gga1000.9.1.2.1 GGA1000 DEC HSG80CCL V88F sg33 dga1.9.1.2.1 DGA1 DEC HSG80 V88F sg34 dga2.9.1.2.1 DGA2 DEC HSG80 V88F sg35 gga998.9.2.2.1 GGA998 HP MSA CONTROLLER 7.20 sg36 dga100.9.2.2.1 DGA100 HP MSA VOLUME 7.20 sg37 dga101.9.2.2.1 DGA101 HP MSA VOLUME 7.20 sg38 dga102.9.2.2.1 DGA102 HP MSA VOLUME 7.20 sg39 dga103.9.2.2.1 DGA103 HP MSA VOLUME 7.20 sg40 dga104.9.2.2.1 DGA104 HP MSA VOLUME 7.20 sg41 dga105.9.2.2.1 DGA105 HP MSA VOLUME 7.20 sg42 dga106.9.2.2.1 DGA106 HP MSA VOLUME 7.20 sg43 gga1000.9.3.2.1 GGA1000 DEC HSG80CCL V88F sg44 dga1.9.3.2.1 DGA1 DEC HSG80 V88F sg45 dga2.9.3.2.1 DGA2 DEC HSG80 V88F sg46 gga999.9.4.2.1 GGA999 HP MSA CONTROLLER 7.20 sg47 dga100.9.4.2.1 DGA100 HP MSA VOLUME 7.20 sg48 dga101.9.4.2.1 DGA101 HP MSA VOLUME 7.20 sg49 dga102.9.4.2.1 DGA102 HP MSA VOLUME 7.20 sg50 dga103.9.4.2.1 DGA103 HP MSA VOLUME 7.20 sg51 dga104.9.4.2.1 DGA104 HP MSA VOLUME 7.20 sg52 dga105.9.4.2.1 DGA105 HP MSA VOLUME 7.20 sg53 dga106.9.4.2.1 DGA106 HP MSA VOLUME 7.20 sg54 gga1000.9.5.2.1 GGA1000 DEC HSG80CCL V88F sg55 dga1.9.5.2.1 DGA1 DEC HSG80 V88F sg56 dga2.9.5.2.1 DGA2 DEC HSG80 V88F sg57 ewa0.0.0.2.0 EWA0 DE500 00-0b-cd-f4-c5-97 eth2 100Mb full- duplex
P00>>> show device f fga0.0.0.0.1 FGA0 KGPSA 1000-0000-c92b-116c fgb0.0.0.1.1 FGB0 KGPSA 1000-0000-c93a-389c fgc0.0.0.2.1 FGC0 KGPSA 2100-00e0-8b1c-d44a To setup a boot or dump device on the console, multiple paths may be given so that at boot time all devices are tried, and malfunctioning paths are skipped. For example, to setup boot for dga100:: P00>>> set bootdef_dev dga100.10.0.0.1,dga100.10.1.0.1,dga100.8.0.1.1,dga100.8.1.1.1 In this case we setup four paths (there are six available in this configuration) which will be tried one at a time if we boot. To boot from a specific path we can also give the complete path to the boot command: P00>>> boot dga100.10.1.0.1 If we do not give a path but just the device name (dga100), the console will attempt to boot from the first device it finds. Page 89
June 2018 vtServer® Reference Manual v3.2.0
The GGA devices are created for the LUNs from the storage controllers itself and will be visible in VMS. They can be used to talk to the controllers with the appropriate utilities (set host/scsi, msa$util, etc.).
10.12. MOP boot Booting from a MOP server (v3 and v4) is possible in the SRM console for all network controllers except the EI1000 adapter.(no VMS boot driver available for EI1000) >>> boot [-file filename] [-flags bootflags] [ -protocol mopv3/4] device
10.13. Clock_mode in SRM console In the SRM console the “clock_mode” variable can be used to force the emulator to use the local time of the vtServer host or force an invalid time so it will always ask to enter the time. Possible values are “normal”, “localtime”, “force_invalid” >>> set clock_mode “localtime”
10.14. Installing Tru64 on a Fibre Channel Disk (vtAlpha only) Some special handling is required when installing Tru64 on a Fibre Channel disk. For this the console has the wwidmgr utility embedded, just like a real system. Before installing Tru64 on a Fibre Channel disk, the disk needs to be configured with the wwidmgr before it is recognized. wwidmgr supports the following commands: wwidmgr -clear This will erase all previous settings and starts with a clean configuration. wwidmgr -show adapter This will show all Fibre Channel adapters on the virtual system: P00>>> wwidmgr -show adapter item adapter WWN Topo [0] fga0.0.0.0.1 2000-0000-c92b-116c FABRIC [1] fgb0.0.0.1.1 2000-0000-c93a-389c FABRIC [2] fgc0.0.0.2.1 2000-00e0-8b1c-d44a FABRIC wwidmgr -show wwid This will show all Fibre Channel devices that can be used for installation: P00>>> wwidmgr -show wwid [0] udid:100 wwid:01000010:6008-05f3-0006-aa30-a01d-7565-96a1-000f (ev:none) [1] udid:101 wwid:01000010:6008-05f3-0006-aa30-a01d-7573-f10a-0010 (ev:none) [2] udid:102 wwid:01000010:6008-05f3-0006-aa30-a01d-757b-6d40-0011 (ev:none) [3] udid:103 wwid:01000010:6008-05f3-0006-aa30-a01d-7586-c4fb-0012 (ev:none) [4] udid:104 wwid:01000010:6008-05f3-0006-aa30-a01d-758d-34eb-0013 (ev:none) [5] udid:105 wwid:01000010:6008-05f3-0006-aa30-abe9-c1bd-40cf-0016 (ev:none) [6] udid:106 wwid:01000010:6008-05f3-0006-aa30-a01d-7585-f31e-0015 (ev:none) [7] udid:1 wwid:01000010:6000-1fe1-0000-1570-0009-0220-7484-0169 (ev:none) [8] udid:2 wwid:01000010:6000-1fe1-0000-1570-0009-0220-7484-015f (ev:none) If installation on the device with udid 105 is desired then this needs to be done:
Page 90
June 2018 vtServer® Reference Manual v3.2.0
wwidmgr -quickset -udid 105 After this it will be known to the console: P00>>> wwidmgr -quickset -udid 105 P00>>> wwidmgr -show wwid [0] udid:100 wwid:01000010:6008-05f3-0006-aa30-a01d-7565-96a1-000f (ev:none) [1] udid:101 wwid:01000010:6008-05f3-0006-aa30-a01d-7573-f10a-0010 (ev:none) [2] udid:102 wwid:01000010:6008-05f3-0006-aa30-a01d-757b-6d40-0011 (ev:none) [3] udid:103 wwid:01000010:6008-05f3-0006-aa30-a01d-7586-c4fb-0012 (ev:none) [4] udid:104 wwid:01000010:6008-05f3-0006-aa30-a01d-758d-34eb-0013 (ev:none) [5] udid:105 wwid:01000010:6008-05f3-0006-aa30-abe9-c1bd-40cf-0016 (ev:wwid0) [6] udid:106 wwid:01000010:6008-05f3-0006-aa30-a01d-7585-f31e-0015 (ev:none) [7] udid:1 wwid:01000010:6000-1fe1-0000-1570-0009-0220-7484-0169 (ev:none) [8] udid:2 wwid:01000010:6000-1fe1-0000-1570-0009-0220-7484-015f (ev:none) Notice the ev: field which indicates that the device is now known in the wwid0 console variable: P00>>> show wwid0 wwid0 105 1 WWID:01000010:6008-05f3-0006-aa30-abe9-c1bd-40cf-0016 At the same time this will initialize the console variables N1 and N2 which are holding the port names of the controller for that device: P00>>> show n* N1 500805f30006aa31 N2 500805f30006aa39 The wwidmgr settings will be saved in the nvram file. On real systems the wwidmgr commands need to be followed by an init command; on vtAlpha this is not needed.
10.15. Pre-defined vtAlpha/vtVAX Installation (Installation Auto-Pilot) The pre-defined installation feature provides the capability to automate all or part of the vtServer software installation and configuration process. One or more customized configuration templates are provided to the end-user on removable media such as DVD, CD, or USB storage device. The user may select from one of several templates, if desired. If there is a need to provide the custom installation data and the vtServer software on the same installation media, please contact your vtServer support provider for assistance. The media containing the custom templates is formatted as a Linux–compatible file system, such as ext3. The template files are contained in the directory /vtServer/templates, each template in a separate subdirectory. The main component of a template is the file parameters.conf. The files presetup.sh and postsetup.sh are optional bash shell scripts that can be used to perform additional installation- specific processing. As the names suggest, presetup.sh is invoked before the installation process is started and postsetup.sh after the installation has completed. If the return status from presetup.sh is zero (0) the installation will continue; any other return status aborts the installation process. The return status of postsetup.sh is not checked. The optional file /vtServer/templates.conf is used to add template options to the boot menu. Examples of all four files are provided below, following the configuration parameters.
Page 91
June 2018 vtServer® Reference Manual v3.2.0
The template configuration parameters are explained in the following sections. Comments may be inserted by beginning the line with the hash or pound character (#).
TPL_KEYBOARD This option allows the selection of the keyboard language for the system. The allowed values are: "Arabic" "Belgian" "Canadian (Multilingual)" "Croatian" "Czech (qwerty)" "Czech" "Danish" "Dutch" "Dvorak" "English (UK)" "English (US)" "Estonian" "Finnish" "French (Canada)" "French (Switzerland)" "French" "German (Switzerland)" "German (with deadkeys)" "German" "Greek" "Hungarian" "Icelandic" "Italian" "Japanese" "Khmer" "Korean" "Lithuanian" "Norwegian" "Polish" "Portuguese (Brazil -- US accents)" "Portuguese (Brazil)" "Portuguese" "Russian" "Serbian" "Simplified Chinese" "Slovak (qwerty)" "Slovak" "Slovene" "Spanish (CP 850)" "Spanish (Latin America)" "Spanish" "Swedish" "Tajik" "Traditional Chinese" "Turkish" "Ukrainian" If not specified, "English (US)" will be used. Example: TPL_KEYBOARD="English (UK)"
TPL_TIMEZONE This option allows the selection of the keyboard language for the system. The allowed values are: "Europe/Amsterdam" "Europe/Andorra" "Europe/Athens" "Europe/Belgrade" "Europe/Berlin" "Europe/Bratislava" "Europe/Brussels" "Europe/Bucharest" "Europe/Budapest" "Europe/Chisinau" "Europe/Copenhagen" "Europe/Dublin" "Europe/Gibraltar" "Europe/Guernsey" "Europe/Helsinki" "Europe/Isle_of_Man" "Europe/Istanbul" "Europe/Jersey" "Europe/Kaliningrad" "Europe/Kiev" "Europe/Lisbon" "Europe/Ljubljana" "Europe/London" "Europe/Luxembourg" "Europe/Mariehamn" "Europe/Madrid" "Europe/Malta" "Europe/Minsk" "Europe/Monaco" "Europe/Moscow" "Europe/Oslo" "Europe/Paris" "Europe/Podgorica" "Europe/Prague" "Europe/Riga" "Europe/Rome" "Europe/San_Marino" "Europe/Samara" "Europe/Sarajevo" "Europe/Simferopol" "Europe/Skopje" "Europe/Sofia" "Europe/Stockholm" "Europe/Tallinn" "Europe/Tirane" "Europe/Uzhgorod" "Europe/Vaduz" "Europe/Vatican" "Europe/Vienna" "Europe/Vilnius" "Europe/Volgograd" "Europe/Warsaw" "Europe/Zagreb" "Atlantic/Reykjavik" "Atlantic/Azores" "Atlantic/Canary" "Europe/Zurich" "Europe/Zaporozhye" "America/Anchorage" "America/Adak" "America/Phoenix" "America/Chicago" "America/Indiana/Indianapolis" "America/Indiana/Knox" "America/Detroit" "America/Denver" "America/Los_Angeles" "America/New_York" "America/North_Dakota/New_Salem" "America/Puerto_Rico" "America/St_Thomas" "Pacific/Honolulu" "Pacific/Pago_Pago" "America/Halifax" "America/Winnipeg" "America/Toronto" "America/Edmonton" "America/St_Johns" "America/Vancouver" "America/Regina" "America/Whitehorse" "America/Glace_Bay" "America/Moncton" "America/Goose_Bay" "America/Blanc-Sablon" "America/Montreal" "America/Nipigon" "America/Thunder_Bay" "America/Iqaluit" "America/Pangnirtung" "America/Resolute" "America/Atikokan" "America/Rankin_Inlet" "America/Rainy_River" "America/Swift_Current" "America/Cambridge_Bay" "America/Yellowknife" "America/Inuvik" "America/Dawson_Creek" "America/Dawson" "America/Argentina/Buenos_Aires" "America/Argentina/Catamarca" "America/Argentina/Cordoba" "America/Argentina/Jujuy" "America/Argentina/La_Rioja" "America/Argentina/Mendoza" "America/Argentina/Rio_Gallegos" "America/Argentina/San_Juan" "America/Argentina/San_Luis" "America/Argentina/Tucuman" "America/Argentina/Ushuaia" "America/Araguaina" "America/Bahia" "America/Belem" "America/Boa_Vista" "America/Campo_Grande" "America/Cuiaba" Page 92
June 2018 vtServer® Reference Manual v3.2.0
"America/Eirunepe" "America/Fortaleza" "America/Maceio" "America/Noronha" "America/Porto_Velho" "America/Recife" "America/Mazatlan" "America/Mexico_City" "America/Tijuana" "America/Antigua" "America/Anguilla" "America/Aruba" "America/Asuncion" "America/Barbados" "America/Belize" "America/Bogota" "America/Caracas" "America/Cayenne" "America/Costa_Rica" "America/Curacao" "America/Dominica" "America/El_Salvador" "America/Guayaquil" "America/Grenada" "America/Guadeloupe" "America/Guatemala" "America/Guyana" "America/Havana" "America/Jamaica" "America/La_Paz" "America/Lima" "America/Managua" "America/Martinique" "America/Montevideo" "America/Nassau" "America/Panama" "America/Puerto_Rico" "America/Santiago" "America/St_Thomas" "Pacific/Easter" "Pacific/Galapagos" "Europe/Kaliningrad" "Europe/Moscow" "Europe/Samara" "Europe/Volgograd" "Asia/Anadyr" "Asia/Irkutsk" "Asia/Kamchatka" "Asia/Krasnoyarsk" "Asia/Magadan" "Asia/Novosibirsk" "Asia/Omsk" "Asia/Sakhalin" "Asia/Vladivostok" "Asia/Yakutsk" "Asia/Yekaterinburg" "Asia/Almaty" "Asia/Ashgabat" "Asia/Anadyr" "Asia/Baghdad" "Asia/Bahrain" "Asia/Baku" "Asia/Bangkok" "Asia/Beirut" "Asia/Bishkek" "Asia/Brunei" "Asia/Kolkata" "Asia/Colombo" "Asia/Damascus" "Asia/Dhaka" "Asia/Dubai" "Asia/Gaza" "Asia/Hong_Kong" "Asia/Irkutsk" "Asia/Jakarta" "Asia/Jerusalem" "Asia/Kabul" "Asia/Karachi" "Asia/Kamchatka" "Asia/Kathmandu" "Asia/Krasnoyarsk" "Asia/Kuala_Lumpur" "Asia/Kuwait" "Asia/Macau" "Asia/Magadan" "Asia/Manila" "Asia/Nicosia" "Asia/Novosibirsk" "Asia/Omsk" "Asia/Phnom_Penh" "Asia/Pyongyang" "Asia/Qatar" "Asia/Rangoon" "Asia/Ho_Chi_Minh" "Asia/Sakhalin" "Asia/Samarkand" "Asia/Tashkent" "Asia/Tehran" "Asia/Thimphu" "Asia/Vladivostok" "Asia/Yekaterinburg" "Asia/Tokyo" "Asia/Shanghai" "Asia/Beijing" "Asia/Taipei" "Asia/Seoul" "Asia/Riyadh" "Asia/Singapore" "Asia/Tbilisi" "Asia/Tokyo" "Asia/Ulaanbaatar" "Asia/Vientiane" "Asia/Yakutsk" "Asia/Yerevan" "Mideast/Riyadh87" "Mideast/Riyadh88" "Mideast/Riyadh89" "Australia/Lord_Howe" "Australia/Darwin" "Australia/Brisbane" "Australia/Adelaide" "Australia/Sydney" "Australia/Broken_Hill" "Australia/Hobart" "Australia/Currie" "Australia/Melbourne" "Australia/Perth" "Africa/Addis_Ababa" "Africa/Algiers" "Africa/Bamako" "Africa/Brazzaville" "Africa/Cairo" "Africa/Casablanca" "Africa/Ceuta" "Africa/Dakar" "Africa/Dar_es_Salaam" "Africa/Djibouti" "Africa/Freetown" "Africa/Johannesburg" "Africa/Kampala" "Africa/Khartoum" "Africa/Kinshasa" "Africa/Kigali" "Africa/Libreville" "Africa/Lusaka" "Africa/Maputo" "Africa/Mogadishu" "Africa/Monrovia" "Africa/Nairobi" "Africa/Tripoli" "Africa/Tunis" "Africa/Windhoek" "Pacific/Auckland" "Pacific/Fiji" "Pacific/Guadalcanal" "Pacific/Guam" "Pacific/Midway" "Pacific/Nauru" "Pacific/Palau" "Pacific/Pitcairn" "Pacific/Tahiti" "Pacific/Pago_Pago" "Pacific/Port_Moresby" "Pacific/Easter" "Atlantic/Bermuda" "Atlantic/Azores" "Atlantic/Canary" "Atlantic/Reykjavik" "America/Godthab" "Indian/Cocos" "Arctic/Longyearbyen" "America/Godthab" "Antarctica/South_Pole" "CET" "CST6CDT" "EET" "EST" "EST5EDT" "GMT" "GMT+0" "GMT-0" "GMT0" "Greenwich" "HST" "MET" "MST" "MST7MDT" "NZ" "NZ-CHAT" "Navajo" "PST8PDT" "UCT" "UTC" "Universal" "W-SU" "WET" "Zulu" "Etc/GMT+1" "Etc/GMT+10" "Etc/GMT+11" "Etc/GMT+12" "Etc/GMT+2" "Etc/GMT+3" "Etc/GMT+4" "Etc/GMT+5" "Etc/GMT+6" "Etc/GMT+7" "Etc/GMT+8" "Etc/GMT+9" "Etc/GMT-1" "Etc/GMT-10" "Etc/GMT-11" "Etc/GMT-12" "Etc/GMT-13" "Etc/GMT-14" "Etc/GMT-2" "Etc/GMT-3" "Etc/GMT-4" "Etc/GMT-5" "Etc/GMT-6" "Etc/GMT-7" "Etc/GMT-8" "Etc/GMT-9" "Etc/GMT" "Etc/GMT+0" "Etc/GMT-0" "Etc/GMT0" "Etc/Greenwich" "Etc/UCT" "Etc/UTC" "Etc/Universal" "Etc/Zulu" If not specified then the default will be "Europe/Amsterdam" Example: TPL_TIMEZONE="US/Eastern"
TPL_HARDDISK This definition is mandatory in a template. This will select the hard disk for the vtServer system. It may be specified as an absolute device name like "/dev/sda" but be aware that device names may change when attaching an external USB device. The USB device may get that name assigned which will lead to an overwritten device. For
Page 93
June 2018 vtServer® Reference Manual v3.2.0
that reason it is only advisable to use absolute device names when using a template that is stored on the vtServer installation DVD. An alternative is to use a pseudo name that will describe the disk, like "hd1" for the first hard disk, "hd2", for the second one, etc. Example: TPL_HARDDISK="hd1"
TPL_HARDDISK_SYSTEM_SIZE This will select the system partition size in GB. If the size is 0, the complete disk will be used for the system partition. If not specified, the default will be 0 (use the complete disk). Example: TPL_HARDDISK_SYSTEM_SIZE=20
TPL_HARDDISK_FORMAT This selects the filesystem format for the specified hard disk. Valid formats are "ext4" or "btrfs". If not specified then it will default to btrfs. Example: TPL_HARDDISK_FORMAT="btrfs"
TPL_HARDDISK_SEC_LABEL If the system disk has space left after creation of the system partition, a second partition will be created covering the rest of the disk. This option allows assignment of a label to that partition which will be used as a mountpoint. If not specified, the default will be "data" eventually followed by a number (like "data1") if there is already an existing partition with that label. Example: TPL_HARDDISK_SEC_LABEL="datadisk"
TPL_DATASTORE TPL_DATASTORE creates a new datastore (partition) on the specified device. The device name is provided in the same format as the value provided for TPL_HARDDISK (see above), Multiple datastores may be created; the index number in square brackets uniquely identifies each datastore. TPL_DATASTORE_LABEL and TPL_DATASTORE_SIZE (see below) must be specified for each datastore created. Example: TPL_DATASTORE[1]="hd2" creates a new datastore on the second hard disk.
TPL_DATASTORE_LABEL TPL_DATASTORE_LABEL is used to specify the name of a datastore. The datastore is identified using the index number used to create it. Example: TPL_DATASTORE_LABEL[1]="datastore1"
TPL_DATASTORE_SIZE
Page 94
June 2018 vtServer® Reference Manual v3.2.0
TPL_DATASTORE_SIZE is used to specify the datastore size in GB; use 0 to allocate all unallocated space on the disk to this datastore. The datastore is identified using the index number used to create it. Example: TPL_DATASTORE_SIZE[1]=100
TPL_DATASTORE_FORMAT This selects the filesystem format for the specified datastore. Valid formats are "ext4" or "btrfs". If not specified then it will default to ext4. Example: TPL_DATASTORE_FORMAT[1]="btrfs"
TPL_VIRTUAL_DISK This option will create a virtual disk (container file) in the specified directory. The path needs to be inside a datastore, and may contain one or more subdirectories that will automatically be created. Example: TPL_VIRTUAL_DISK[1]="/datastore1/disks/dka100.vdisk"
TPL_VIRTUAL_DISK_SIZE This selects the size for the specified container file in 512-byte blocks. This needs a number inside square brackets to select the appropriate virtual disk. Example: TPL_VIRTUAL_DISK_SIZE[1]=4110480
TPL_IP_INTERFACE This option specifies the network interface (used by the vtServer host) to use for setting up IP configuration parameters. Example: TPL_IP_INTERFACE="eth0"
TPL_IP_ADDRESS This option specify the IP address for the TPL_IP_INTERFACE. The IP address may also be specified as "dhcp" to get an address via DHCP. These setting will override the network parameters from a full configuration import. Example: TPL_IP_ADDRESS="192.168.0.100"
TPL_IP_NETMASK This option specify the IP network mask for the TPL_IP_INTERFACE. These setting will override the network parameters from a full configuration import. Example: TPL_IP_NETMASK="255.255.255.0"
TPL_IP_GATEWAY This option specify the default gateway for the TPL_IP_INTERFACE. These setting will override the network parameters from a full configuration import. Example: TPL_IP_GATEWAY="192.168.0.1"
Page 95
June 2018 vtServer® Reference Manual v3.2.0
TPL_IP_DNS1,2,3 This option specify the DNS server for the TPL_IP_INTERFACE. These setting will override the network parameters from a full configuration import. Example: TPL_IP_DNS1="192.168.0.2”
TPL_HOSTNAME This option specifies the fully qualified hostname (used by the vtServer host). Example: TPL_HOSTNAME="vtalpha.example.com"
TPL_LICENSE_SERVER This option specifies the IP address or DNS domain name of one or more external license servers. This needs a number inside square brackets to select the appropriate server. Example: TPL_LICENSE_SERVER[1]="licenseserver.example.com"
TPL_COPY_SRC This option allows copying a file from the template directory (or subdirectory) to a datastore. The filename is relative to the template directory. If the file is a compressed file it will be decompressed on the fly at copy time. The compression is done by examining the file extension which determines the compression format. The recognized formats are zip, rar, gz, bz2 and xz. Since a zip or rar file may contain multiple files it will be extracted to the directory specified in TPL_COPY_DST; the other file types are uncompressed and copied to the single file described in TPL_COPY_DST. This needs a number inside square brackets to select the appropriate file. It needs an accompanying TPL_COPY_DST option to select the destination. Example: TPL_COPY_SRC[1]="vmsdisk.zip"
TPL_COPY_DST This option will set the destination for a file copy. If the destination specifies a subdirectory it will automatically be created. This needs a number inside square brackets to select the appropriate file. It needs an accompanying TPL_COPY_SRC option to select the source. Example: TPL_COPY_DST[1]="/datastore1/vmsdisk.vdisk"
TPL_IMPORT This option will import a previously exported system configuration to the installed system. The file can be exported with the vtServer user interface from a system that was prepared to be used as a template for new systems. The location of the file must be in the template directory or a subdirectory of the template directory. Example: TPL_IMPORT="subdir/production.tgz"
TPL_INSTALLKIT This option allows installation of optional kits from the template directory, or from /kits on the DVD if not found in the template directory. This needs a number inside square brackets to select the appropriate kit. Page 96
June 2018 vtServer® Reference Manual v3.2.0
Example: TPL_INSTALLKIT[1]="avtpatch_nvidia_38.tgz"
TPL_REBOOT This option can be specified to force a reboot at the end of the installation. The value must be either "yes" or "no". If specified as "yes" then the system will reboot after installation, and if specified as "no" then the system will halt after installation. If not specified and TPL_POWEROFF is not specified then the default action will be to reboot the system after installation. Example: TPL_REBOOT="yes"
TPL_POWEROFF This option can be specified to turn off the power after installation. Example: TPL_POWEROFF="yes"
TPL_PASSWORD This option will set the password for the root account. It is mandatory if the TPL_IMPORT option has not been specified. If a configuration is imported then TPL_PASSWORD will overrule the password of the imported configuration. Example: TPL_PASSWORD="secret"
TPL_CONFIRM This option allows an installation without further user action. Normally when not specified the user is required to accept or reject the template right before starting the installation. Setting TPL_CONFIRM to "no" will skip that step and start the installation right away.
10.15.1. Example parameters.conf # set the keyboard language TPL_KEYBOARD="English (US)"
# use the second hard disk in the system as the vtServer system disk TPL_HARDDISK=hd2
# and make it a 20GB partition TPL_HARDDISK_SYSTEM_SIZE=20
# label the second partition (it has the rest of the disk space) TPL_HARDDISK_SEC_LABEL="secdata"
# create a 2GB datastore on the third hard disk and label it "data1" TPL_DATASTORE[1]=hd3 TPL_DATASTORE_LABEL[1]=data1 TPL_DATASTORE_SIZE[1]=2
# create another datastore on the same disk, use the rest of the # disk space and label it "data2" TPL_DATASTORE[2]=hd3 TPL_DATASTORE_LABEL[2]=data2 TPL_DATASTORE_SIZE[2]=0
# create a 50000 blocks (25MB) container file in the /data1 datastore TPL_VIRTUAL_DISK[1]=/data1/vd1.vdisk TPL_VIRTUAL_DISK_SIZE[1]=50000
# create a 60000 blocks (30MB) container file in the /data2 datastore TPL_VIRTUAL_DISK[2]=/data2/vd2.vdisk TPL_VIRTUAL_DISK_SIZE[2]=60000
Page 97
June 2018 vtServer® Reference Manual v3.2.0
# create a 10000 blocks (5MB) container file in the /secdata datastore TPL_VIRTUAL_DISK[3]=/secdata/vd3.vdisk TPL_VIRTUAL_DISK_SIZE[3]=10000
# copy and uncompress a g-zipped CD # notice that .gz files need a destination file specification TPL_COPY_SRC[1]="Application Installation CD.gz" TPL_COPY_DST[1]="/data1/Application Installation CD.iso"
# copy and uncompress a zip archive to /data2 # notice that .zip files need a directory specification TPL_COPY_SRC[1]="Zippedfiles.zip" TPL_COPY_DST[1]="/data2"
# copy a prepared virtual disk container file TPL_COPY_SRC[2]="testdisk.vdisk" TPL_COPY_DST[2]="/data2/testdisk.vdisk"
# import a previously prepared system configuration TPL_IMPORT="vtAlpha_21-May-2014_083853.tgz"
# install the nvidia display driver kit TPL_INSTALLKIT[1]="avtpatch_nvidia_38.tgz"
# add two different license servers TPL_LICENSE_SERVER[1]="license1.example.com" TPL_LICENSE_SERVER[2]="license2.example.com"
# setup the vtServer host ip parameters TPL_IP_INTERFACE="eth0" TPL_IP_ADDRESS="192.168.13.199" TPL_IP_NETMASK="255.255.255.0" TPL_IP_GATEWAY="192.168.13.254" TPL_IP_DNS1="192.168.13.254" TPL_IP_DNS2="10.13.0.1"
# overrule a saved password from the imported configuration TPL_PASSWORD="secret"
# halt the system after installation TPL_REBOOT="no"
# confirm the installation template before starting the # actual installation TPL_CONFIRM="yes"
10.15.2. Example presetup.sh script #!/bin/bash
# we are called with the following arguments: # $1 = template directory # $2 = presetup configuration file (to return new # parameter settings to the caller) # $3 = logfile # $4 = AVTDEBUG (debug flag)
# some constants for the dialog box
export ESCDELAY=50 DIALOG=/vtAlpha/utils/dialog DIALOG_OK=0 DIALOG_CANCEL=1 DIALOG_HELP=2 DIALOG_EXTRA=3 DIALOG_ITEM_HELP=4 DIALOG_ESC=255
Page 98
June 2018 vtServer® Reference Manual v3.2.0
# we need a temp file tempfile1=`mktemp -u`
# get the template name out of the template directory templatedir="$1" if [ "$templatedir" ] then template="`basename $1`" fi presetup="$2" logfile="$3"
# read all default parameters from our template file . "$templatedir/parameters.conf"
# setup for host network device eth0 TPL_IP_INTERFACE="eth0"
# invoke the dialog, feed it the defaults we have read from parameters.conf # and give the use a chance to change the defaults.
$DIALOG --colors --title "Network parameters for template $template" \ --form "Enter network configuration data" \ 15 40 0 \ "interface:" 1 1 "$TPL_IP_INTERFACE" 1 13 -8 8 \ "address:" 2 1 "$TPL_IP_ADDRESS" 2 13 16 0 \ "netmask:" 3 1 "$TPL_IP_NETMASK" 3 13 16 0 \ "gateway:" 4 1 "$TPL_IP_GATEWAY" 4 13 16 0 \ "dns1:" 5 1 "$TPL_IP_DNS1" 5 13 16 0 \ "dns2:" 6 1 "$TPL_IP_DNS2" 6 13 16 0 \ "dns3:" 7 1 "$TPL_IP_DNS3" 7 13 16 0 \ 2>$tempfile1
# check if the input was accepted if [ $? -eq $DIALOG_OK ] then
# the input is accepted, setup the new parameters
TPL_IP_ADDRESS=`cat $tempfile1 | head -1` if [ ! "$TPL_IP_ADDRESS" ] then TPL_IP_ADDRESS="0.0.0.0" fi TPL_IP_NETMASK=`cat $tempfile1 | head -2 | tail -1` if [ ! "$TPL_IP_NETMASK" ] then TPL_IP_NETMASK="0.0.0.0" fi TPL_IP_GATEWAY=`cat $tempfile1 | head -3 | tail -1` TPL_IP_DNS1=`cat $tempfile1 | head -4 | tail -1` TPL_IP_DNS2=`cat $tempfile1 | head -5 | tail -1` TPL_IP_DNS3=`cat $tempfile1 | head -6 | tail -1`
# and finally write the new parameters back to the presetup configuration file
echo "TPL_IP_ADDRESS=\"$TPL_IP_ADDRESS\"" >>$presetup echo "TPL_IP_NETMASK=\"$TPL_IP_NETMASK\"" >>$presetup echo "TPL_IP_GATEWAY=\"$TPL_IP_GATEWAY\"" >>$presetup echo "TPL_IP_DNS1=\"$TPL_IP_DNS1\"" >>$presetup echo "TPL_IP_DNS2=\"$TPL_IP_DNS2\"" >>$presetup echo "TPL_IP_DNS3=\"$TPL_IP_DNS3\"" >>$presetup fi
Page 99
June 2018 vtServer® Reference Manual v3.2.0
# remove the temp file rm -f $tempfile1
# return with 0 means success, any other status aborts the installation exit 0
10.15.3. Example postsetup.sh script #!/bin/bash
# $1 = template directory # $2 = presetup configuration file (to return new # parameter settings to the caller) # $3 = logfile # $4 = AVTDEBUG (debug flag)
# some constants for the dialog box
export ESCDELAY=50 DIALOG=/vtAlpha/utils/dialog DIALOG_OK=0 DIALOG_CANCEL=1 DIALOG_HELP=2 DIALOG_EXTRA=3 DIALOG_ITEM_HELP=4 DIALOG_ESC=255
logfile="$3"
# the setup is complete. ask if we need to show the logfile
$DIALOG --clear --title "Setup complete" --defaultno \ --yesno "Do you want to view the log?" 5 32
# check if the input was accepted if [ $? -eq $DIALOG_OK ] then
# ok, show the logfile
$DIALOG --clear --title "Setup log" --no-collapse --cr-wrap \ --msgbox "`cat $logfile`" 24 80 fi
# there's no need to return an exit status as all actions are # finished by now.
10.15.4. Example template.conf The file template.conf is used to add templates to the vtServer boot menu. This example assumes that there are 3 subdirectories created in ‘/vtServer/templates’, with the names ‘vaxwork’, ‘Alphaspecial’ and ‘Big Workstation’. All names are case sensitive.
timeout 0 default vaxwork
label vaxwork kernel /boot/vmlinuz append root=/dev/disk/by-label/vtServer_dvd initrd=/boot/initrd console=tty2 quiet loglevel=2 splash=silent vga=0x314 1 ro avtinstall avtdvdinstall template=vaxwork showopts
Page 100
June 2018 vtServer® Reference Manual v3.2.0
label Alphaspecial kernel /boot/vmlinuz append root=/dev/disk/by-label/vtServer_dvd initrd=/boot/initrd console=tty2 quiet loglevel=2 splash=silent vga=0x314 1 ro avtinstall avtdvdinstall template=Alphaspecial showopts
label Big Workstation kernel /boot/vmlinuz append root=/dev/disk/by-label/vtServer_dvd initrd=/boot/initrd console=tty2 quiet loglevel=2 splash=silent vga=0x314 1 ro avtinstall avtdvdinstall template="Big Workstation" showopts
Page 101