I run ArcGIS on OSX pretty much every day using VMWare. The only difference is that I do not have it installed in a Virtual Machine - it is a bootcamp partition - and let me explain to you why, IMHO, this has more advantages over a standard VM installation for ArcGIS.
First let's take VMWare out of the equation and talk about pure Bootcamp.
When you use Bootcamp, you are actually creating a separate partition for Windows on your disk. They are completely separate installations of Operating Systems. At boot time you can hold the option key and choose whether you boot to Windows or boot to OSX. As long as you have the proper bootcamp Windows drivers installed, this guarantees that it is the fastest way you can run Windows on that hardware since it is only running on Windows at that point. The disadvantage is clear - you need to pick what OS you are going to run at startup time and if you need to switch OS, well you have to reboot.
Yeah that sucks.
Welcome to VMWare Fusion. VMWare allows you to do two things with Bootcamp. One of them is import your bootcamp partition into a new virtual machine effectively creating a full clone of that bootcamp partition and dumping it in a VM inside OSX - do NOT do this.
The other thing that it allows you to do is to boot your Bootcamp partition from inside OSX by accessing that portion of the disk. This is cool and is what I use. Make sure that you do have the VMWare tools installed in your bootcamp partition when you run it from within OSX - otherwise things are slow.
What this configuration allows you to do is to choose how fast you want ArcGIS to run.
When you want the advantage of running both OSX and Windows, you can use VMWare Fusion and run your Bootcamp partition virtualized.
When you want maximum ArcGIS speed, reboot the machine and use it natively.
As far as how many resources to give Windows when running in inside OSX, I usually give it half of whatever I have (half memory, half CPUs) and this seems to work optimally. Since I have all the drivers installed for whatever mode I am running (bootcamp drivers and vmware fusion tools), it runs fine in either mode.
In regards to your question of ArcPy - don't get fooled by what Unity Mode in VMWare Fusion is doing. It is allowing you to make it seem like Windows and OSX are running as one because the individual windows looks the same - but they are still, mostly, isolated. Yes you have access to both file systems and network resources, but that's pretty much it. So you can your ArcPy from the windows environment just fine... but don't expect to be able to "import" any libraries that you have installed only on the OSX side and everything will work fine - those are two isolated python environments and if you wanted to have this work you are getting too greedy :)
Viewing the contents of a file geodatabase OR editing its contents using an Esri product, it doesn't matter which, will produce a .LOCK file inside the file GDB's folder on the file system which can be seen via Windows Explorer. It will contain some numbers in its filename, one of which refers to the process ID (PID) of the active process connecting to it. To know which process or application has your FGDB locked, open Task Manager and explore the contents of your GDB folder on the file system using Windows Explorer. Add the PID field to Task Manager and then compare the process IDs in Task Manager to that of the lock file to identify the culprit. The presence of the .LOCK file is essentially an exclusive lock and won't allow you to do much else other than view the FGDB contents until it is gone. Killing those connections can be done by ending the process brutally in Task Manager or gracefully closing an application or stopping a GIS service, if applicable.
Now, if there is no lock file or process holding on to the FGDB, then you probably have a system lock of some sort that hasn't cleared up. Rebooting should resolve that; but if rebooting isn't possible then you'll need to close the FGDB files manually. If you have Windows 7 or Server 2008 R2 or higher, read on:
If you are still having issues with deleting a geodatabase on the file system despite the fact that the .lock files no longer exist, it's possible there is still a process lock on one or more of the files within it. That being said, if you're using Windows Server 2008 / Windows 7 or later you can try one of the following methods:
From the Start menu, type FSMGMT.MSC, then multi-select the files you want from the GUI, then right click them and chose "Close". That method should force close the files that are technically still open due to a process lock.
or
From a batch file, run the following (example is for a file geodatabase) to close a file named a00000225.gdbtable (this filename is just an example):
cd C:\this_server\directory\subdirectory
for /f "skip=4 tokens=1,2*" %%a in ('net files') do if %%b == C:\this_server...\a00000225.gdbtable net file %%a /close
You can modify the command above to loop through all of the files in the file geodatabase to close them all rather than specify them individually, which would be tedious since there are so many.
From the command prompt, type NET FILES to see what the bold text above should contain.
Remember that double percent characters are required for batch files (in other words, %% rather than %) but single percent characters are used when running the command outside of a batch script.
Best Answer
After contacting the appropriate IT admin, I recieved the following instructions, resulting in load times closer to my expectation: ArcMap now takes ~4s, ArcCatalog ~3s to load.
run "esriremove.reg" to remove changes made by ArcGIS to the registry, the contents of esriremove.reg are:
re-install the single-user / off-site license (I had started with the single-user / off-site license, so this is not in and of itself the only issue).