I finished downloading and installing Windows 7 this weekend. It didn’t take nearly as long as I thought it would take and I do have to hand it to the guys at Redmond: Good Job! I was able to get the OS installed on VMWare Fusion 2.0.1 with no issues. Other than to play with Windows 7, I did have a purpose to installing the OS — but since installing it I completely don’t need the OS any more other than a play thing on the Mac.
Whew.. I’ve missed this program a lot since losing my VMWare Vista client. I’ve just downloaded and installed Windows 7 on VM and it seems to be working. I’ll have another blog entry about that. But for now, I think the most important thing that help resolve some of my networking issues with both Vista and Windows 7 clients is switching to NAT addressing rather than bridging with the new version of VMWare Fusion – 2.0.1.
I now simultaneously run a client VM and Mac software at the same time without losing any networking on the Mac side. Entirely too bizarre and I’m happy just to have a work around.
Looks like they also upgraded the software since the last time I used it. Looks like we’re up to Build 14.
I was lucky to get hit by a power outage today. Nothing like running around the house putting out blinking 12:00s. I thought that would be the worse of it – I was wrong. As my Mac powered on it started throwing errors about not able to mount drives, etc. Then I realized that some of my internal servers may not have survived the power outage.
As it turn out my main VMWare server machine did just fine – and it spun-up a majority of my VMs that I have running on that server. However, I quickly discovered that a crucial VM, my Active Directory-DNS-DHCP Win2K3 server, did not power up. No wonder I couldn’t hit any internal servers. Launching into VMWare Server console to launch the VM manually gave me the bad news – VMWare threw back an error of “Fail to lock the file” — the file being the VM.
A little Google search later, I found this blog article that seem to have the answer. Basically remove the lock files. The article mentions that the lock files end with a “.LCK” extension. In my instance, running VMWare server, the lock files have an extension of “.WRITELOCK”.
I moved the “.WRITELOCK” files to a temp directory and attempted to restart the VM and – SUCCESS.
I was so happy .. for 10 minutes then I got hit with another power outage.
Standardizing on one VM platform has made my life so much easier. I’ve played with a number of them and I’ve settled on VMWare. Currently, I have an Ubuntu Server running VMWare in my basement and I have a number of client machines that have VMWare client software running as well. Recently I’ve noticed a deficiency when I move my main computing platform to Mac OSX — there is no VMWare Server Console software.
This software is very valuable if you are running multiple VMs on a VMware server. Instead of configuring a remote control or SSH server on each client VM, you can control the VMs via the VMWare Server Console. When my main computing platform was Ubuntu Gusty Gibbon, this was a no-brainer. The software is bundled with the Linux client package. Running Gusty Gibbon on my primary PC was amazing because I could not only control another VMWare Server, the workstation had multiple client OS’s installed locally so I could have a dozen machines running on two physical pieces of hardware. But then I made the switch….
Just a quick tip – I noticed lately that whenever I fire up a VM on my machine, ALL four processors would shoot up to 90+% utilization. In addition, the VM (typically running Vista) would take a good 10-15 minutes to load (okay, a bit of an exaggeration – but it took forever.) Took me a couple of minutes to figure out that it was my anti-virus software that was causing the issue.
As I mentioned before in a previous post, I’ve installed ClamXav software on my Macs because of the rising popularity of Macs (this begets challenges to hackers which begets to virus being written for OSX, etc. — or is that just my paranoia?) The program installs easily enough and updates itself regularly etc.
If you are using ClamXav Sentry and VMWare, you MUST exclude any VM images from being scanned! Better yet, make sure that you configure your ClamXav Sentry to ignore scanning the directory in which you keep your VM images. This will dramatically increase the start time of any VM. If you opt for the extension method of exclusion, VMs have an extension of .vmwarevm .