Workstation 8 with Studio 2.5

...does work, with some assumptions. The new Workstation 8 literally merges the Server product-line (ex-GSX) with the Workstation product line, that's called VMware Workstation-Server service. It supports autostart features and finally a usable remote management interface, by using another workstation as client. It also supports the workstation as a client of ESXi5 or vSphere5, but that's off-topic now.
So, this server-service runs on Linux64 at my box, and I'm using it as a build-host for my Studio 2.5 projects. On WKS7, You had to run the Workstation with #/usr/bin/vmware all the time You wanted to run a VM. That called for a vncserver of course. Now, WKS8 supports running VMs as a service. The issue is: if You try to build a Studio VM, You still have to run the Workstation GUI (on the vncserver for example), otherwise the build will fail. This limitation will probably disappear in the next version of Studio. Also, old build VMs stay in the WKS library, even after deleting their files, this worked in WKS7 better.

Studio updater

I am playing with VMware Studio 2.5 now (great stuff btw), and seem I found a strange bug.
I am using Workstation 7 on Linux64 as the build host, and I try to create an update repository. It builds the VM, but when updating the repo the following error message appears in the build log:

Unable to create directory at manifest
; shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
pushd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
mkdir: cannot create directory `manifest': No such file or directory
It only occurs, when I choose not to build the ZIP archive, only OV*. Should test it on WKS8, but I guess it's a Studio problem. More to come later.

3D in Linux Workstation

The VMware Workstation on Linux does support 3D, however certain distributions (including Slack 13.37) does not ship with the S3 - now who remembers that company? - Texture Compression libraries, because of some licensing issues (see http://dri.freedesktop.org/wiki/S3TC). This occurs as an error message when running the VM "3D graphics acceleration will be disabled. This computer does not have a 3D graphics system supported by VMware Workstation.". In the VM's vmware.log file, in the same directory as the .vmx You should find some lines like "mks| VMGL: Extension missing, GL_EXT_texture_compression_s3tc", and "mks| GLManager: Required extension GL_EXT_texture_compression_s3tc is missing." and "mks| msg.glBackend.initFailed] 3D graphics acceleration will be disabled. This computer does not have a 3D graphics  system supported by VMware Workstation.". This means exactly as stated, You miss a .so file from You /usr/lib or /usr/lib64 respectively. You should just simply download the libtxc from the site above (direct link is http://cgit.freedesktop.org/~mareko/libtxc_dxtn/snapshot/libtxc_dxtn-1.0.1.zip), compile and place the .so in Your libs dir. That's all, next run, Windows 7 should enable Aero effects in Workstation on Linux!

KIES in Workstation

It is possible to run Samsung KIES (Galaxy family) in VMware Workstation on linux. You need to disable 3D acceleration in the vmx file (a black window occurs if it is enabled when starting KIES), and maybe some USB quirks from this forum post. Just a quickie, because the 3D disable thing is not obvious.

7.1.3 -> 7.1.4

Workstation 7.1.3 still requires the -I (Ignore scripting errors) to uninstall before installing 7.1.4. And 7.1.4 still requires to rm -rf /etc/vmware* before installing itself. Lame.
I don't think there is much slackware64 QA at VMware's.

7.1

Had to use vmware-installer -I -i vmware-workstation to remove the RC.
Then rm -rf /etc/vmware-installer to make the new one run.
The new release is 261024. Im courius if 3D got working on Linux host at last (it broke for me on 7.1 beta). This VMGL thing might earn a look-at.

VMware Workstation 7.1 RC out

As seen above.
One thing to note: After uninstalling the Beta, some installer database files remain in /etc/vmware*, which makes the new installer think of a false dependency (vmware-player e.x.p. requirement).
These files shall be deleted before a successful RC installation.
This happened to me on linux x64.

Workstation, with ESX inside

I'm using VMware Workstation since the 2.x series. Currently 7.1 Beta on Linux x64. I'm now used to the -I parameter which is required for installing/uninstalling, I have some perl lib error or such which breaks the installer script.
The other thing I noticed is the new opengl support on linux. This broke entirely my Windows 7 guest's direct3D. Every time I try to run the Windows Experience Index, it just coredumps. Probably I would need to install some gl libs for the Linux, I'm just lazy.

But get to the point:

My favorite feature is the ability to run ESX in the WKS of course. Did this before with the monitor_control.restrict_backdoor on the 6.x series, but it's now extremely easy. The only thing You have to watch out is promiscuous mode. If You are not running WKS as root (I hope You don't), You will get the message about promiscuous mode is not enabled for security reasons. This is a bit false, it means the user running the process does not have the permission to use a file in the /dev filesystem. It is fairly easy to dodge this ofc., just by reading the KB. The trickier part is when You set up a team, and use a private lan segment. Than You have to chown/chmod the vmnet0 interface, which is not documented anywhere. Also, I set /proc/sys/vm/swapiness on the host to 40, to make it swap as little as possible when running a team of 3 VMs.

If You are running a team with a private lan, than You probably do this to have more than 1 ESX-VM. I used a linked clone of a freshly installed esx (3.5u5) to create a second one, with minimal disk usage. After I set up both of them, and an XP VM as vCenter, I found an interesting scenario. Both of them could ping the vCenter, the vCenter could ping both of them, but they could not each other.

The solution was tricky. As others might know, the service console is a virtual interface. The linked clone was made after the fresh install, with a service console already present. And of course, as a virtual NIC, it has a virtual MAC address too...
So I had 2 ESX boxes with the same SC MAC. First thing to do is to drop the vswif0 from CLI esxcfg-vswif -d vswif0. Then, when I recreated it (esxcfg-vswif -a -p "Service Console" -i 192.168.69.12 -n 255.255.255.0 vswif0), it "generated" the same HW address again! The same happened after I dropped vSwitch0 too (esxcfg-vswitch -d vSwitch0; esxcfg-vswitch -a vSwitch0; esxcfg-vswitch -L vmnic0 vSwitch0; esxcfg-vswitch -A "Service Console" vSwitch0). It would be obvious to use just vswif1 instead, but then, how do I change the MAC of a service console?
Redhat. The vswif0 interface's MAC is in /etc/sysconfig/network-scripts/ifcfg-vswif0. After changing the MACADDR line in there, just run ifdown vswif0 && ifup vswif0 and done.
This is only true for ESX. On  ESXi, You have to edit /etc/vmware/esx.conf, as ESXi does not have ifconfig command, or vswif0 interface, just vmk0 and esxcfg-vmknic.
As stated above, I used VI3, but I'm pretty sure, that things are the same in vSphere.

After I had 2 working ESX VMs, I used an NFS datastore for shared storage. The HA needed das.isolationaddress config, as the private lan segment did not have a gateway. Using the vCenter's IP as a GW works too. Now I can ran Tinycore in a VM in ESX in a VM in WKS. Takes about 10 mins to boot tough...