VMware Fusion Evaluation

Since much of my job involves rolling out Linux solutions I’ve been experimenting with VMware Fusion Beta for the Macintosh in my development environment. Given that the product is still in beta, I have very few complaints about its actual stability. Most of the features work reliably as advertised, but there are some basic points of functionality that I feel the software is lacking. More on that later.

First, let’s take a look at exactly what VMware Fusion is. At its core, the package allows the user to create and run virtual machines on the Macintosh. For those who are new to virtualization, it is a way to run multiple virtual computers on one actual computer. The hardware resources are abstracted and shared to the virtual machines through the virtualization software — in this case VMware Fusion. A complete description on virtualization can be found here.

Previous to Fusion, only VMware player was available to Macintosh users, so it is nice to actually be able to create virtual machines locally. The snapshot feature is also very nice for development purposes since you can instantly roll back to a previous working state should you corrupt the software on the virtual machine.

Perhaps the problem that annoyed me most, however, was the fact that there is no clear way to delete virtual machines from within the software. I actually tried to get rid of one by deleting this folder:

/Volumes/Macintosh HD/Users/myaccount/Documents/Virtual Machines/Mymachine.vmwarevm

But I just ended up breaking the “Virtual Machine Library” application and having to uninstall and reinstall everything from scratch. The process detailing how to delete a virtual machine did not exist anywhere in the VMware Fusion FAQ or documentation as far as I could tell. Granted, it’s beta software, but I would think this should be a core feature of any virtualization product. At least they provide an “Uninstaller” script.

VMware Fusion is a basic piece of software that succeeds in fulfilling the most fundamental of virtualization requirements. If all you want to do is be able to run a virtual machine or two on your Mac, it will most likely work for you. If you are looking to deploy it as part of an enterprise solution, I would suggest letting the product mature a while and using something like Parallels instead.

Using My New Mac Mini

My new Mac Mini came in yesterday and I just got it all up and running. I had some misgivings about allowing the system to transfer over all my applications and information from the old system, but I went ahead and did it anyhow simply because I seriously doubted I could find all the CD’s for my software. For the most part, the process went smoothly, although I had to do a little cleanup afterwards because a few applications did not work after the migration.

I was also a bit concerned about what kind of performance I would get out of the new Intel processor because many of my applications are older and were compiled on the old PPC chips. This has turned out to be a total non-issue! I got the new Mini fully loaded with a 1.83Ghz Intel Core Duo processor, 2 Gigs of RAM, and a 160 Gig SATA drive, so even the older applications that require the carbon libraries scream right along.

While I would have obviously liked to get the Mac Pro, I am very much enjoying using my new Mini, and feel that I can recommend it fully.

Macintosh Finder Copy to Samba Share Problem

With the last Samba upgrade, we started having problems copying files to our Samba share from the Mac OSX finder.When attempting the copy we received an error reading: “The operation cannot be completed because you do not have sufficient privileges for some of the items.”

There were no permissions issues, which was substantiated by our unhindered ability to do UNIX copies to the same share, and the smb.conf file had not changed. After searching the groups and finding nothing of use, I set up a test environment with all the same versions and settings, and replicated the error.

Because the Samba share is mounted over NFS on the server, and because the Mac Finder creates that annoying place holder file before actually copying the real file, I suspected that the problem had something to do with file locking. With this in mind, I systematically turned off all Samba locks one by one until I found the ones that worked.

Finder Copy Error

Finder Copy Error

IMPORTANT NOTE: The Samba share point in this environment is mounted over NFS on the server. The error did not occur when the Samba share point was on a filesystem local to the server.

Here is what our share looked like before making the changes:

[your-directive]
read only = no
preserve case = yes
short preserve case = yes
csc policy = disable
share modes = no
level2 oplocks = no

Adding either of the two following directives resolved the problem:

locking = no
posix locking = no

Either one would have worked, but we ultimately decided to turn off posix locking because we wanted Samba to continue locking files for Windows connections, but stop locking them over NFS. Below is our share after making the change:

[your-share]
read only = no
preserve case = yes
short preserve case = yes
csc policy = disable
share modes = no
posix locking = no
level2 oplocks = no

The smb.conf man page has the following to say about posix locking:

posix locking
The smbd daemon maintains an database of file locks obtained by SMB clients. The default behavior is to map this internal database to POSIX locks. This means that file locks obtained by SMB clients are consistent with those seen by POSIX compliant applications accessing the files via a non-SMB method (e.g. NFS or local file access). You should never need to disable this parameter.

Default: posix locking = yes

The smb.conf man page has the following to say about locking:

locking
This controls whether or not locking will be performed by the server in response to lock requests from the client.

If locking = no, all lock and unlock requests will appear to succeed and all lock queries will report that the file in question is available for locking.

If locking = yes, real locking will be performed by the server.

This option may be useful for read-only filesystems which may not need locking (such as CDROM drives), although setting this parameter of no is not really recommended even in this case.
Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter.

No default

Hopefully this is helpful. If anyone has anything to add, please post a comment.