Windows Installation Overview

VOV supports Windows and many UNIX variants. This document goes over issues that you may encounter in setting up a VOV environment in Windows machines.

Note: PowerShell is not supported. When installing or upgrading Altair Accelerator products in a Windows environment, do not use PowerShell.

Windows is Single-User (mostly)

Unlike UNIX, the Windows operating system is oriented toward single-user computers. Windows is multi-tasking: the CPU is shared among many processes, each of which may have one or more threads of execution. When you are logged in to a Windows machine, your user ID owns the resources of that machine. In UNIX-like operating systems, multiple users may be logged in to a machine concurrently, and each user may use whatever resources according to the permissions (rwx) assigned to them. Processes that run as Windows services run in the local SYSTEM account by default, but may also run using a domain account, which can be different from the one logged on to the machine.

Windows NT has a significantly different security model from UNIX systems. The Windows security for domains is based on a centralized user authentication model, where each user's credentials are verified by the primary domain controller when that user logs in. Each machine may also have local machine accounts, but those accounts have no access to network resources. Windows NT object access is based on access-control lists (ACLs), rather than permission bits as in UNIX. The ACL model is more powerful and flexible than the UNIX model.

Windows Networking

Windows networking is very different and, by default, limited compared to UNIX-like operating systems. By design, Windows ships without any remote shell facilities, and remote execution is limited to client-server using remote procedure calls. These limitations have several significant consequences for VOV, which needs a way to remotely start vovtasker processes on the vovtasker machines. Once the vovtasker process is running, it communicates with the server directly via TCP/IP.

The Windows network filesystem model also differs significantly from UNIX-like systems. Most UNIX-like systems use Network File System (NFS), originally developed by Sun Microsystems, and now a public-domain standard. Windows uses the SMB (Server Message Block) protocol, which is also now being called CIFS (Common Internet File System) by Microsoft.

Organize Data into VOV Projects

A basic concern is how to organize your data into VOV projects. You will need to do this whether or not you have any Windows machines. This is a trade-off between the number of projects and servers you will need to maintain, and the complications of setting up operating system permissions to allow all users the read/write access needed to do their work.

Some files are 'primary inputs' to a project, those which appear at the top of the flow graph and are not generated by any job. Examples of such files are source and header files for software projects, or Verilog HDL source files for chip design projects. The files at the bottom of the flow graph, which are not used by any job in the project, are the primary outputs of the project. An example of this might be the executable file built by a VOV software project. These primary outputs could then be primary inputs of downstream projects.

The same principles of modularization and information hiding which apply to software design are also applicable to project and flow design. Judicious choice of project boundaries allows you to hide unnecessary detail and enforce correct information propagation between projects.

Choose VOV Project Server Machine

Each VOV project is managed by a server process, which maintains the project database and interacts with the client processes, such as VOV tasker machines, vovconsole, web browsers, etc.

In a mixed UNIX/Windows environment, you could run project servers either on UNIX or Windows. Running the server on UNIX, and using Windows machines only as taskers is usually a better choice, because of the relative ease of remote administration of UNIX machines. It is, however, possible to create a pure Windows VOV installation.

Choose Windows Tasker Machine Mount Points

The filesystems containing the VOV Windows executables and the project data directories must be mounted on all Windows machines that serve as VOV taskers.

You will need some capability for cross-platform mounting filesystems. A common solution is to run the public-domain Samba software on a UNIX file server, which enables setting up SMB shares of UNIX filesystems. These may be mounted via the 'net use' command from Windows. It is also possible to use NFS client software on Windows machines, but experience has shown this to be an inferior solution, for cost and administrative overhead reasons. To our knowledge, there is not a good public-domain NFS client implementation for Windows.

Another approach is to place the user and project data on a purpose-built fileserver machine which supports both NFS and CIFS, such as a NetApp filer. These machines have a custom-designed operating system which supports serving the same file data using both NFS, CIFS and HTTP. This solution offers high performance and low administrative overhead, but is also costly.

Site-specific vovinit.bat

This application note provides several small example batch scripts that make it easy to mount the filesystems and set up the environment for VOV taskers. You need to decide where your project's is are to be stored, and adapt the .bat files to match your mount point setup. In many cases, you can do it all in one script by customizing your local vovinit.bat file.

The command to initialize a Windows cmd shell for use with VOV is called vovinit. This batch script adds the VOV bin and bat directories to the path, and calls the script $VOVDIR/local/vovinit.bat if it exists. The local vovinit.bat is a good place to put site-wide initialization and variable setup. The following example shows some typical site-specific customizations.

Example script: vovinit.bat
REM mount tools area containing flowtracer WinNT .exe files
if not exist V:\NUL net use V: \\appsrv\tools

set VNCSWD=r:/release/VOV/vnc

REM user Windows home directories
if not exist U:\NUL net use U: \\file01\users

REM -- Optional: update the local disk cache of useful executables.
REM vtclsh %VOVDIR%/tcl/vtcl/vovupdatecache.tcl

REM Synchronize with the timeserver
REM Do this last because it fails if not holding admin rights
net time \\timeserver /set /y
Note: This script first tries to mount the VOV software and user directories. The commented-out vovupdatecache.tcl command updates a local cache directory of executables. This may be used to reduce the load on the fileserver and network, at the cost of local disk space. At the end, the script synchronizes the local system clock with the time server.

Windows Tasker Accessibility Policy and Practices

Many of the Windows machines at most companies are users' desktop machines. If these are to serve as vovtaskers, you need to develop policies and practices about times of availability to avoid the degradation of interactive response time.

If your project needs Windows tasker machines, you have two main choices:
  • VOV supports time-dependent resources, which is one approach to this issue. The resources of a machine may be static or defined by a Tcl procedure in the namespace VovResources. Some example procedures are found in $VOVDIR/etc/tasker_scripts/taskerRes.tcl.
  • Another approach is to dedicate machines other than users' desktop machines to act as VOV Windows tasker machines. This is often done where there is a large Windows component to the workload, such as SmartSpice simulations.

Add Resource Specs to Jobs

If you are reading this Application Note, it is likely you have jobs which can only run on Windows in your project. You must add a resource specification of 'win64' to those jobs, so that VOV will dispatch the jobs to the correct type of machine.

Resources should be specified in the Flow Description file (Flow.tcl) for the project, using the 'R' statement. You may also modify jobs in your project interactively using the Node Editor in the vovconsole. This latter is good for interactive testing, but those customizations will be lost when you rebuild the project unless the resource specifications are in the Flow Definition File.

User IDs that Run Jobs on Windows Tasker Machines

Windows NT does not provide a means to easily switch to the ID of another user. When a user is logged in to a Windows machine, that user owns all the machine's resources. That user must have appropriate permissions in the data directories to access and create or modify files.

The most common solution to this issue is to create a specific UID to own the data for each project, and put that UID and all the users who also need access to the data into a netgroup, giving group write permission.

Start the VOV Tasker Machines

Because Windows does not supply a remote shell capability, VOV provides the vovtsd (Vov Tasker Service Daemon) program to enable Windows machines to act as vovtaskers. This program, once started, listens on a TCP/IP port for incoming tasker start requests. When vovtsd receives a tasker start request, it starts a tasker process, which then communicates directly with the vovserver to receive jobs and return status information.

Usually the TCP/IP port number is derived from the name of the logged-in user, but it may also be specified explicitly. If you use a non-default port, you must also specify that port in the project's taskers.tcl file. Note the use of -vovtsdport in the example below.

After you have started the vovtsd on the Windows tasker machine and configured the taskers.tcl file, you can then start and stop the taskers.tcl process on that machine using the vovtaskermgr command, from the console GUI, or the browser.

Periodic Automated Run and Data Reduction

Once you have set up Windows tasker machines, you will probably wish to run regression tests and other projects periodically and post the results to your internal website. This can be handled using the UNIX 'cron' facility or a Windows 'at' job.

The cron job typically wakes up and runs a vovbuild script which adds a new set to the trace of the project, and then retraces the jobs in that set.

VOV has the vovcrontab command for UNIX, which sets up crontab entries for hourly, daily, weekly, and monthly jobs. These jobs run scripts which are located in the scripts subdirectory of the project configuration directory.

vovserver Configuration

The following section explains the details of how to configure the vovserver to enable Windows tasker machines.

This example shows some selected parts of the server configuration file taskers.tcl, which describes the tasker machine setup. The key difference is that Windows uses drive letters in the names of mount points.

Windows Machines in taskers.tcl File

Because Windows paths include a drive letter, it is not possible to refer to a filesystem using the same path on Windows and UNIX. This means that it is necessary to explicitly specify the path to the VOV software and to the server working directory in the taskers.tcl file when you set up a project. 
# -- lists of various kinds of host platforms
set linHosts { lin1 lin2 lin3 }
set macHosts { mac1 mac2 mac3 }
set winHosts { win1 win2 win3 }

# -- Simple loop to declare UNIX taskers with default parameters
foreach host [concat $linHosts $macHosts] {
    vtk_tasker_define $host
}

# set different defaults for the Windows taskers to follow
# FINE POINT: -serverdir specifies the _parent_
#              of the dir containing configuration files
# NOTE: paths specified with forward slashes, used by Tcl
#       do _not_ use backslashes as hierarchy separator here
vtk_tasker_set_default -vovdir     R:/rtda/2016.09/win64  -serverdir  H:/vov  -vovtsdport 16666

foreach host $winHosts {
    vtk_tasker_define $host
}

Starting Tasker Processes for your Project

  1. Enable your shell for VOV:
    vovproject enable <project_name)
  2. Start the tasker processes:
    vovtaskermgr start <tasker_machine_name>

    If you supply <tasker_machine_name>, then only that machine will be started. Otherwise, all taskers named in the configuration file which are not yet running are started.