When setting up a guest machine's shared folder location (R/W) and installing my guest virtual machine, I do not see where the shared folder is available for mounting from within the guest machine.
Is there a standard drive available I should use to mount the shared location?
VMware tools fail to install properly, so I'm not able to ascertain if that would make any difference or not.
Afflicted OS's I've experienced this with: Solaris Express Developer Edition 5/07, OpenBSD 4.0, and FreeBSD 6.1.
VMware tools fail to install properly, so I'm not
able to ascertain if that would make any difference
or not.
This would absolutely make a difference, shared folders will not work unless tools are installed (note this is different from network shares, which should be fine). Also, I'm not sure what tools support is like on Solaris/*BSD.
At least in Ubuntu, the mount point is /mnt/hgfs/you-shared-folder-name/
VMware tools fail to install properly, so I'm not
able to ascertain if that would make any
difference
or not.
This would absolutely make a difference, shared
folders will not work unless tools are installed
(note this is different from network shares, which
should be fine). Also, I'm not sure what tools
support is like on Solaris/*BSD.
We'll, I thought I'd follow-up to the group so they don't make the same mistake I did. VMware Tools failed to install in Solaris Express Developer Edition 5/07 as the VMware Tools was looking for XOrg 7.1 directory, but only XOrg 6.9 and 7.0 directories were installed with this version of Solaris.
Trying to outwit the installer script, I had copied the contents from the XOrg 7.0 directory to a new directory 7.1 that the VMware Tools installer was looking for. I re-ran the VMware Tools installer and it finished successfully. However, I wouldn't suggest you do this[/b].
Not only did this not work (VMware Tools inoperative), this process crashed not only the current VMware virtual machine, but ALL of my other VMware virtual machines running...a complete program failure from the misconfiguration of one VM.
Lesson learned. If the VMware Tools installer doesn't work and you wish to tinker with it, make backups of your VM before you end up with an unbootable VM and crash your other running VMs.
Hopefully VMware will create a smarter VMware Tools installer script.[/b]
Not only did this not work (VMware Tools
inoperative), this process crashed not only the
current VMware virtual machine, but ALL of my other
VMware virtual machines running...a complete program
failure from the misconfiguration of one VM.
Did it actually crash the other virtual machines, or did it just bring down the UI? It's a bad bug regardless (do you have the log files?), but the the other virtual machines remained running (e.g. you can still see vmware-vmx processes in Activity Monitor with All Processes selected), you can reconnect to them by reopening the virtual machine.
Did it actually crash the other virtual machines, or
did it just bring down the UI? It's a bad bug
regardless (do you have the log files?), but the the
other virtual machines remained running (e.g. you can
still see vmware-vmx processes in Activity Monitor
with All Processes selected), you can reconnect to
them by reopening the virtual machine.
Honestly I didn't look to see if it was just a UI crash or the actual VMs as well as UI. There was no evidence of a VMware process running in the desktop, but I hadn't checked Activity Monitor. I did, however, check one of my VM's that was hosting a website, and it timed out, seeming to indicate all of Fusion crashed. Restarting the UI and connecting to the VM's showed booting from the virtual BIOS. =(
Which log files are you referring to and where would I find them?
I did,
however, check on of my VM's that was hosting a
website, it timed out, seeming to indicate all of
Fusion crashed. Restarting the UI can connecting to
the VM's had the start booting from the virtual BIOS.
=(
Hmm, that does sound like a complete crash.
Which log files are you referring to and where would
I find them?
Each virtual machine keeps rotating log files (vmware.log) in the vmwarevm bundle, which is by default located in ~/Documents/Virtual Machines/. Ctrl-click on it and select "Show Package Contents".
There is also a rotating UI log for Fusion (vmware-vmfusion.log), and it's located in ~/Library/Logs/VMware Fusion/.
Because they're rotating, try to find the one corresponding to the crash (or reproduce the crash and grab the newest logs).
Each virtual machine keeps rotating log files
(vmware.log) in the vmwarevm bundle, which is by
default located in ~/Documents/Virtual Machines/.
Ctrl-click on it and select "Show Package Contents".
There is also a rotating UI log for Fusion
(vmware-vmfusion.log), and it's located in
~/Library/Logs/VMware Fusion/.
That VM package \[directory] was deleted since the VM was hosed from the above process.
Because they're rotating, try to find the one
corresponding to the crash (or reproduce the crash
and grab the newest logs).
All log files have rotated though and none of the current reference the major catastrophe. And NO, I don't wish to recreate that crash again! VMware engineers should be able to replicate this bug easy enough.