>>>Hi
>>>
>>>I'm working with a Client whose workstations are all virtual machines. Since moving to virtual machines we are getting problems with random attempting to lock messages. The user can only exit the application causing any work to be lost.
>>>
>>>Why is a network with virtual machines prone to attempting to lock problems and is there any way of trapping them so that I can discover the cause
>>
>>I have played with virtual machines for just a few months, but didn't run anything in them, just held my SQL Express in one. One thing I learned is that there are several ways to set up networking between the host machine and the VMs, and that this simulated network isn't exactly the same as the real one. My best guess at the moment is to look into that - check the logs. On host or the VMs? Probably both.
>
>Thanks Dragan

If the workstation VMs and/or the data file server machines/VMs are running any antivirus product, you could try temporarily disabling any real-time scanning component, or excluding VFP persistent or temporary files from real-time scanning. That's something easy to try, otherwise it gets more complicated < g >.

To add to Dragan's post, file-server databases like VFP rely on the SMB/CIFS network protocol. VFP is actually a stern test of an SMB implementation; if there are any incompatibilities or misconfigurations, VFP is likely to find them.

SMB is a Microsoft protocol, and only MS has the "real thing" in its Windows OSs. There are other implementations (such as Samba) on other OSs but they have all been reverse-engineered from SMB in Windows.

For best reliability with VFP, the ideal scenario would be if the Windows virtual workstations, and data file server(s) were hosted on Microsoft hypervisor(s) (i.e. Hyper-V), where communications on the virtual LAN within each real box, and between real boxes, is Microsoft SMB. Having said that, even with genuine Microsoft underlying everything there are still at least a couple of potential issues:

1. If the workstation VMs are Vista or later, and the server(s) are Server 2008, by default they will communicate using a newer version of SMB, called SMB2. This can cause corruption with VFP and other file-server databases such as MS Access. There have been some threads here discussing this e.g. Thread#1430067 .

2. Even with genuine Windows you may need to disable "oplocks" on both the virtual workstations and any related server(s) that hold VFP data. Again, there have been threads here on this topic, you can search on "oplocks".

If it isn't genuine Windows/Hyper-V end-to-end, troubleshooting will get more complicated. One possible scenario is you may have the Windows VMs on one non-Windows host (e.g. VMWare), and virtual data server(s) on another non-Windows host (maybe XenServer). Finally, the data server running on XenServer may itself not be a Windows server, but could be some flavour of Linux, with Samba offering SMB services. A single data request from VFP on a virtual workstation to a data server would look something like this:

---------- Host1 Computer running Windows workstation VMs on VMWare -----------
VFP application running on a Windows workstation VM
                   |
                   |
                   V
VMWare virtual (internal) network/switch (including firewall)
                   |
                   |
                   V
Physical Host1 network adapter
                   |
---------- Host1 Computer running Windows workstation VMs on VMWare -----------
                   |
                   V
Real network switchgear (switches, routers etc.)
                   |
---------- Host2 Computer running server VMs on XenServer -----------
                   |
                   V
Physical Host2 network adapter
                   |
                   |
                   V
XenServer virtual (internal) network/switch (including firewall)
                   |
                   |
                   V
Samba SMB data server running on a Linux server VM
---------- Host2 Computer running server VMs on XenServer -----------

In the (extreme) example above, there are several points of potential incompatibility or misconfiguration:

- VMWare virtual network/firewall on Host1
- XenServe virtual network/firewall on Host2
- Samba server on Linux server VM on Host2
- (low probability) The real network switchgear, or physical network adapters on hosts 1 and 2

Virtual networks and Samba servers sometimes have configuration options that let you choose between high performance and high reliability/compatibility. Default settings may be "balanced" between the two. If you're talking with network admins, I'd stress the demanding nature of VFP apps, and suggest they try configurations set to "maximum reliability/compatibility".

You may encounter some resistance if global changes have to be made to hosts, that are running many things other than VFP, just for VFP. In that case you might ask the admins to set up a test environment for you (that's what VMs are good for), or otherwise get creative :)