Virtualbox 4.1.8 allows VMS clustering LAVC

I tried to change the adapter type.

Windows created a new adapter, and would not let me name it the same name as the one that it replaced, so I named it VMS_INT2.

Then the Virtual Alpha configuration tool would not allow me to change the configuration, it would not list the new adapter. I could not get it to do so.

So I use wordpad/write to modify the config file. The change was not shown in the configuration tool. I had exited the tool while editing the .cfg file.

So I put the network interface back and rebooted.

The configuration utility would not allow me to set the network adapter back, and attempting to start the emulator complained about not finding the adapter name I hand edited.

I exited the utility and hand edited the config file, then the configuration tool could find it and the emulator started.

Try re-installing FreeAXP. WinPCAP needs to find the new adapter.

I put the network adapter in a comatose state by trying a compile from the NFS mounted source disk.

Then I discovered that the PUTTY terminal in the emulator, and it looks like the entire Windows GUI was running several seconds behind real time.

Trying again with current patches on the Windows 7 64 bit, and Virtualbox 4.1.18.

First try failed. The NFS_SERVER password had expired. I thought I had marked it as not expirable.
After using the local user manager in the control panel to mark the account to never have the password expire or allow it to be changed, I was able to start the NFS. VMS would still not mount it until I rebooted the Windows VM.

Looks like there still may be something in Windows 7 and Virtualbox and the FreeAXP that is shutting down interfaces on high network I/O, as UBUNTU with SimH has never been affected.

Will try to do a compile tomorrow again.

I may have to rebuild both the Windows and Linux VMs for the older VirtualBox to get stable again.

From Dave Hittner:

It would help to know what versions of software you are running.

OpenVMS 8.4 w/ TCPIP 5.7 and all TCPIP ECO’s up to the current ECO3 have some severe NFS client defects from the TCPIP 5.7 NFS subsystem rewrite which cause NFS performance degradation (by 10-1000X) and NFS hangs.

I (and others) have reported at least four major NFS client bugs, some of which have hot fixes, and some of which are still being addressed by OpenVMS engineering.

I’d suggest moving the NFS-based files to a local disk and retrying the operation.

There may be something to his comment that the system time is off, which could be a symptom of high virtual host I/O denying processing time to the virtual systems.

I am running AXPVMS 8.3, idle 1.1, TCPIP V5.6-9.

I made no comment about system time being off. Character echo from putty was about 10 seconds before I rebooted the emulator. The dropbox.com application was also very far behind in reporting updates.

But now that you mentioned time, I do see that the cluster and the Windows VM are not in agreement on time.

I fixed the time and did the search again in a subprocess. It hung as before.

I have always had problems with VMS 8.3 alpha on the emulator doing DCL searches of text files on NFS volumes.

But at this point, I have not lost the cluster, just that subprocess, which is easily killed.

The reason for the NFS volumes is that the dropbox.com application is keeping the directories backed up and I also have two other VMS systems that are not in the cluster that are also doing builds off of those directories.

I have not upgraded this system to 8.4 as I want to have an 8.3 system to compare changes in the API behavior.

The configuration is now Virtualbox 4.2.4 r81684 on OS-X 10.6.8\ 4 CPU.

The Windows VM is Window 7 64 bit, 4 CPU.

FreeAXP 2.2.1.453

As soon as I tried doing major NFS transfers, the network interface on Windows used by the emulator stopped passing traffic until the Windows VM was rebooted.

I changed the the network adapter on that was hanging on the Windows VM from being the paravirtualized driver (virtio-net) to be the "Intel PRO/1000 MT Server (82545)", and adjusted the FreeAXP configuration file to use it.

This is less efficient than using the paravirtualized driver.

Now though, driver is not shutting down. Occasionally I am getting a per-process NFS hang, but other processes still have access through the network interface.

So there is an issue with VirtualBox and the paravirtualized driver Windows Driver that can be triggered using VMS 8.3 TCPIP 5.6-9 on FreeAXP.