I'm looking into this right now. Using NI-488.2 in Virtual Machines is not something that has been fully tested right now
OK, So, I know I'm on the bleeding edge...
Server is an HP Proliant DL380 with 1 Xeon E5345 2.33 GHz 4 core processor. Hyperthreading disabled. 14GB RAM. 949.25GB RAID 5 Disk array.
Running VMWare ESX on bare metal. VM image has Windows XP installed in 15GB virtual disk. Allocated 512MB RAM with unlimited CPU. Has three virtual network interfaces enabled in this image. 1 for intranet server access, 1 for subnet containing product under test, 1 for subnet containing instrumentation (gpib-enet, serial server, etc.).
There are currently only two (yes 2) users on this machine. We are in an early state of implementation; and, expect to have 20-40 users on the server eventually.
We have a GPIB-ENET connected to same switch as Bosonova thin client and serial server. Connection to server is via D-Link wireless bridge which has a good 54Mbit connection to building wi-fi infrastructure. Infrastructure backhaul from Xirrus wi-fi array to server is 1 Gbit.
Everything works fine as long as we don't try to throttle the CPU allocation for the session. We're running some legacy code that, shall we say, isn't very thrifty in it's utilization of CPU. As a result, we need to throttle the session so it doesn't eat up all the CPU cycles on the core it's running on, limiting available resources to other sessions. The problem occurs when we try to do this, limiting the allocated CPU resources. Prior to running the test, we set the resource allocation and restarted the VM with the new settings. The session (Windows) appeared to be functioning correctly in that we could run programs that did not use the GPIB interface. When starting our test application, the VM crashes and reboots on a GPIB function call. The problem is repeatable. It goes away when the VM is restored to unlimited CPU. The last CPU setting we tried was 600MHz equivalent (limit to maximum of 25% of one core)
