Technogeezer's Posts

Thoughts: You did say your XP VM runs fine, correct? Are all the appropriate services running on your SBS server? Is the "Server" service still running? Does Task Manager on the server show any process consuming an inordinate amount of CPU? If you have a physical Vista machine, can it access the SBS server without issue? Are you able to copy that file down to your Vista machine (not open it via Word) and then open it locally? If not, does a dialog box appear that seems to count down the time remaining on the copy, but never completes (0 seconds remaining)? If this happens, check with Microsoft - I've Googled and found that there's a hotfix that fixes that problem.

Something is causing your server's file sharing services to hang, and I would not rule out a Vista interaction with your server. I assume that your 2003 SBS machine is a physical, not virtual, machine. I'd start with the Windows SBS server. Check its event logs to see if there are any suspicious entries in any of the logs at the time your Vista VM hung. As well, are there any entries in the Vista VM's event logs?

Don't worry about the names - what's important is what they're connected to. I suspect that your converted VM has 2 virtual NICs defined. All you need to do is to find out which one goes where... In the Windows VM, open a command line and type : ipconfig /all This should give you the details about the IP addresses for your network connections - which should match up with how your virtual NICs are configured. If you don't like the names, then highlight them, right click and rename them. Nothing stopping you from making them something more meaningful (or not..).

It's a bit of a trick getting into Safe Mode - blame both Fusion and XP for this What makes it difficult is a) you have to get keyboard focus back into the VM very quickly at boot time, and 2) Microsoft ships XP by default without enabling the ability to select an OS to boot (this would give you time and a good indication of where to hit the F8 key). Here's how I've done it Shut down your VM. You should now have the window with the great big triangular play button in it. Click the play button to start the VM. You will see the BIOS stuff start to flash by. At this point, immediately hit the Command (NOT CONTROL, but the key with the "Apple" or funny squggly character to the left of the space bar) then G keys. The arrow or hand cursor will disappear, indicating that the VM has keyboard focus. Now hit the F8 key a few times. If you've got the timing right, you'll then see the Windows Advanced Options menu from which you can select Safe Boot. If you don't have the timing right, you'll see the normal XP startup window. Let it boot, shut down the VM, and try again.

You do not have to create a Boot Camp partition to run Fusion. If you create a VM using the "New" button in the Virtual Machine Library, the VM will be created as files on your Mac's hard drive in your Documents/Virtual Machines folder (along with your other files). Once the creation of the VM is complete, you should see it as an entry in the Library. Highlight it and click the "Run" button to start it. I think you're misinterpreting the instructions regarding Boot Camp. The "Boot Camp Partition" will only appear in the virtual machine library if you have a Boot Camp partition and Windows is installed in that partition per Apple's Boot Camp instructions.

First, re-installing Fusion isn't appropriate at this time as there's nothing here that indicates that there's a Fusion problem. It's unlikely you would have gotten this far if Fusion was installed incorrectly or was missing pieces. Second, let's try getting the Windows Installer working for you. See the instructions in Microsoft KB315346 (Error message when you try to add or remove a program on a computer that is running Windows XP or Windows Server 2003: "The Windows Installer service could not be accessed"): at http://support.microsoft.com/kb/315346 I'd start with method 1 to re-register the Windows Installer. If this method doesn't work for you, you'll have to attempt method 2. You can download the file onto your Mac, then either burn it to CD (good place for a CD-RW so you don't waste a disk), or see if you can get a USB stick to work. If we can get the installer working, then we can probably get VMware Tools installed and the network working. Just for information, does XP think that SP2 got installed?

You have a couple of options to share files on that external HD: 1, Drag and drop 2. Set up Shared Folders for the VM 3. Turn on Windows Sharing on the Mac and access the Mac as a network share from XP. 1 & 2 are the easiest to set up and may work for you, but others have experienced some intermittent problems. 3 would probably work as well, but may need you make some configuration changes on the Mac to see that external drive. Those changes either involve manually editing the Samba smb.conf file to make the external drive a share, or create aliases/symbolic links from your home directory to the external drive.

I wholeheartedly agree that snapshots are not really backup or a replacement for backup with TM, SuperDuper! or manually copying a VM off-disk. I use them to freeze a known good copy of a VM, run it (I do a lot of product demos using VMware), then roll back the snapshot so that the VM is pristine for the next demo iteration. Saves having to go back to the backup to undo changes that I don't want to save permanently. Just another tool in the ol' bag of tricks.

"Allocated disk size" has nuances when dealing with virtualized disks (especially when you define virtual disks that aren't fully allocated at creation time). The XP environment sees a virtual disk of the size that you created. From the Mac side, there's a relationship between the used space reported by XP and the size of the .vmdk files in the virtual machine bundle - but not a strict correspondence. The size on the Mac side will be at least the amount reported by windows, and perhaps more depending how XP has allocated disk space and how you've defined the virtual disk. Also, as etung has noted, snapshots can increase Mac disk usage up to 2x the max size of the virtual disk. That being said, it's important to be precise about where the disk is being reported as being used. Are you saying that the XP installation is running out of space? When you say 1.3 gigs and 3.7 gigs are being used, which OS is reporting that? XP or Mac? Is there a snapshot active (the Fusion GUI will tell you this)? Which OS said it was using 30 GB or 10GB? IIf space is being "hogged" from within the XP guest, then you should be scrutinizing the use of the disk from the XP standpoint. it's not uncommon for a XP guest to use more space when applying Microsoft updates. XP updates not only get loaded down to your system (depending on Automatic Updates preferences), but their installation saves away copies of files they're replacing so they can be backed out. I've also seen updates that you don't want to apply (IE7 comes to mind) sitting in XP because they got downloaded by Automatic Updates. You also have the virtual memory file within XP (page file) that can expand automatically (up to the limits that are configured). Do you have any other software beside the OS installed in your XP guest, such as AV or utilities? Automatic defrag utilities could cause excessive allocation on the Mac side for expandable disks, as they have to move data around on to what they think is unused disk space to do their work. When a disk is allocated sparsely, the "unused" space isn't really there on the Mac's disk - Fusion will have to add it to the virtual disk when the XP guest wants to use it. Using a snapshot does not double the disk requirement - it can take up to 2x the space (an important distinction) depending on activity on the virtual disk and the way the virtual disk was created. What the snapshot does is freeze the original disk. As changes are made, changes get recorded in the files that represent the snapshot. So the size taken up by the checkpoint is proportional to changes that occur since the snapshot was taken. If you take a snapshot and you don't change much, you don't use much extra disk space. Change everything on the XP disk, and you use closer to 2x the disk space that you would normally use. You don't want to disable the use of snapshots (they're very useful when you want to roll back changes you've made to a VM - like protecting yourself against problems encountered when you do a software upgrade). I disagree that it's a prescription for disaster. As with any feature, use it judiciously. I would not have a snapshot active all the time, just turn it on when you need it, and remove it when done. Message was edited by: Technogeezer: Added commentary on snapshot disk utilization

Can you give us a few more details on what's happening as you upgrade? What version of VMware Tools do you have installed in your XP guest, and what version are you trying to upgrade to? What is the error you are getting on upgrade? Have you tried uninstalling VMware Tools, rebooting your XP guest, them re-installing VMware Tools? The version of VMware Tools that ships with 1.1.1 is the same as that in 1.1 (the build numbers are different but there are no code changes according to VMware) and that a Tools upgrade is not necessary.

They do seem to work OK for me - haven't had a problem yet. I looked at what Dave's scripts do, and compared the Fusion 1.1 and 1.1.1 boot.sh initialization scripts, and didn't find anything that the new version of Fusion did that would break Tokamak.

This is puzzling. Fusion (or even Parallels for that matter) itself shouldn't be growing a guest OS's disks at 1GB per 16 hours while "idle". Rather than immediately start to work on disk management, you probably should try to find out exactly what is growing to consume the disk space. When this happens, does your VM report increasing disk space? Are there files in the virtual machine bundle which keep growing? Are you sure there's no background task in your VM that wants to read the disk or is running out of control, filling up the disk? Use of checkpoints can cause increased disk consumption, but only if the VM is writing something. If you're running 10.5 Leopard, there are reports here in the community about interactions with Time Machine and sync'ing with iDisk, which, if turned on, can cause the Mac's system dsks to fill up.

This does not look at all like output from any Microsoft-created Windows XP boot CD I've ever seen. Whatever it is, it appears to want to find a formatted disk - which it won't find with Fusion until Windows writes the MBR and a partition table. Find a genuine Microsoft Windows XP installation CD (not something created by someone at work) and see if that works.

If it ain't broke, don't fix it. By "connections" I assume you mean your virtual network settings - they're part of the VM and won't be touched. If you do decide to take the plunge to 1.1.1, here's what I'd do: Back up your entire system. I use SuperDuper to clone my hard drive to another disk such as an external USB or FireWire drive - makes it really easy to reboot on the clone and then put your hard drive back exactly the way it was before you started. It's a safety net that you can use as a last resort should all other attempts to get things working fail. This will also back up your VMs should they be on your hard drive. Record your permanent license key. Just in case. You also should have a back-out strategy. Mine was: Uninstall 1.1.1 using the uninstallation script. Reboot. Remove the /LibraryApplication Support/VMware Fusion directory. Re-install 1.1 (and re-install the license key if needed). If all else failed to get Fusion to work again, boot the system off the cloned copy, and clone it back onto the hard drive. I guess I was lucky in my upgrade from 1.1 to 1.1.1. I uninstalled the old version of Fusion using the provided uninstaller script, rebooted, and then installed 1.1.1. My license key was found, so I didn't have to re-enter it. Everything else worked fine.

KennyL is correct, you can purchase Fusion from any retailer, online or brick-and-mortar, as well as directly from VMware. What's important is getting that permanent license key. Heads-up, though. Any box product you get (from any source) may contain the Fusion 1.0 release. I assume that since you have a 30-day trial, you are running at least 1.1. If you are, do nothing except install the permanent license. You won't want to mess up a perfectly working environment. If you're running 1.0, revisit the VMware web site and download 1.1 or 1.1.1. The permanent Fusion license key you get with your purchase can be used on 1.0, 1.1, or 1.1.1 versions.

I interpret etung's response as: The version (7.6.2) of VMware tools is the same between 1.1 and 1.1.1, as it is the same code. My guess is that any Tools upgrade process would see the version being the same and not touch anything. The build number change just appears to be an artifact of the Fusion release process - they just re-built the 7.6.2 version of Tools along with 1.1.1. A Fusion uninstall/reinstall is probably a waste of time. If the date stamp on the ISO files in /Library/Application Support/VMware Fusion/isoimages is around January 18, 2008, then the product upgrade went fine. I would expect that installation of Tools in a new guest would reflect 7.6.2 and the new build number.

Ahhh. So the version of Tools really didn't change for Windows (which I did notice), but the build number did. So if I understand correctly, the same code base of Tools got built in both 1.1 and 1.1.1. So does the build number change reflects that it was built along with Fusion 1.1.1?

I saw this as well with an XP guest that I've got. Upgraded Fusion to 1.1.1, and then I went to install the VMware tools in the XP guest. After "installation", I found that the build was still noted as 62573 in the guest's VMware tools "About" box. I double checked the ISOs that got installed by the Fusion 1.1.1 upgrade. They matched those in the Fusion 1.1.1 installation bundle. So I'm thinking either a packaging error or an installation issue within the guest.. At this point, I de-installed VMware Tools in my XP guest and then re-installed them. VMware Tools in the guest now reports the tools build as 72241. Weird...