The skinny :
To use VMware Fusion's vmrun from the command line (i.e. Terminal), you must invoke it with its FULL PATH, even if you are already in the same directory as vmrun lives in.
The fat :
Continuing to prove that VMware is great when it works and quite lousy when it doesn't, get this :
I opened Terminal.
I cd'ed to /Applications/VMware\ Fusion.app\Contents\Library.
I tried to execute "vmrun".
"Command not found"
How can that be?!! The command is definitely in that directory!
ls -l
Yup - there it is, vmrun, and all users have execute permission.
I lost probably half an hour on this stupid bug.
Turns out that the solution is simple, but horribly inobvious :
You must include the full path to vmrun every time you invoke it, even if you are already in the same directory as it!!!
So instead of bothering to cd to the enclosing directoy, just always use :
/Applications/VMware\ Fusion.app/Contents/Library/vmrun
Note : I tried adding the directory to my PATH to see if that way I could run vmrun just with "vmrun", but it didn't work.
Sunday, July 20, 2014
Thursday, July 17, 2014
VMware Fusion Converter VSS issues
VMware is simultaneously both very nice and very frustrating.
I have a 4.5 year old laptop (Sony Vaio Z) running Windows 7 Ultimate, and decided to virtualize it. Great idea!
VMware Fusion comes with a physical-to-virtual converter. Piece of cake!
But every time I try, I get the big bad message :
"An Error Occurred
"The VSS snapshots cannot be stored because there is not enough space on the source volumes or because the source machine does not have any NTFS volumes. Error code: 2147754783 (0x8004231F)."
Thanks VMware!
So here are some of the things I tried that have helped not a bit :
The VSS service was creating error log entries claiming that there is an "Unexpected error calling routine ConvertStringSidToSid" (0x80070539). This is what led me to wonder if checkdisk might be needed - but that didn't help - and is also what led me to the MaxTokenSize trick linked above, which also didn't help. However, after deleting that "*.bakk" registry entry, the VSS service has produced no more error messages - yet the error message from the VMware Converter remains the same, blaming VSS.
It's not inspiring that multiple other people online seem to have given up on this one. (e.g.)
I also report with disappointment that this was not my first unfavourable experience with this supposedly easy physical-to-virtual conversion tool. About a week ago I converted a Surface Pro 2 (Windows 8.1) physical to virtual prior to sending it in for servicing. I also had a lot of trouble then, although finally managed to get it to work. Two bad experiences out of two attempts. Relatively useless documentation. Sadly, this is my experience of VMware so far : It is awesome when it works, and an extreme pain when it doesn't, which is far too often.
I have a 4.5 year old laptop (Sony Vaio Z) running Windows 7 Ultimate, and decided to virtualize it. Great idea!
VMware Fusion comes with a physical-to-virtual converter. Piece of cake!
But every time I try, I get the big bad message :
"An Error Occurred
"The VSS snapshots cannot be stored because there is not enough space on the source volumes or because the source machine does not have any NTFS volumes. Error code: 2147754783 (0x8004231F)."
Thanks VMware!
So here are some of the things I tried that have helped not a bit :
- I spent a long time clearing stuff off the 147GB C: drive until there was over 10% of the drive free. Still kept complaining.
- I disabled my R: drive RAM disk. It was an NTFS drive, but just in case somehow it was causing trouble, I completely turned off the RAM drive system. (Note that I had P2V'ed a Windows 8.1 machine with a RAM disk successfully, using the same tool, so this never seemed likely to be the problem.)
- I suspended BitLocker in case that was somehow interfering (although note that I had P2V'ed a Windows 8.1 machine with BitLocker successfully, using the same tool, so this also seemed unlikely to cause the problem).
- I adjusted a MaxTokenSize registry setting.
- I completely disabled "previous versions".
- I fully enabled "previous versions" (both for my files and for operating system files - i.e. the highest level) and allocated it 10% of the available space.
- I deleted all existing previous versions. If you're doing the maths, this means there are roughly 14GB available and allocated to VSS. So space shortage is not the problem here!
- I confirmed that there are no other mounted drive letters - I removed all USB sticks and external drives.
- I confirmed that there are no unmounted volumes on the one internal drive, other than a 15MB one that appears to be a boot volume and is nearly entirely full but I doubt there's anything much I can do about it.
- I created a new administrative user and tried using that account instead of my normal administrative account when doing the physical-to-virtual conversion.
- I did a full checkdisk scan on a reboot - i.e. whilst the C: drive was not in use.
- I rebooted the Mac OS/X computer that was on the receiving end of the process.
- And of course, throughout the above I rebooted the Windows laptop many times over.
- I discovered a "bakk" (yes - double 'k') entry in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList as discussed here, deleted it and rebooted, and same problem (although strangely & interestingly, laptop shutdown and boot times were much improved, or so it seemed to my subjective impression!).
- I also verified that the other SIDs in that registry key were all valid (using psgetsid from PSTools as described here).
The VSS service was creating error log entries claiming that there is an "Unexpected error calling routine ConvertStringSidToSid" (0x80070539). This is what led me to wonder if checkdisk might be needed - but that didn't help - and is also what led me to the MaxTokenSize trick linked above, which also didn't help. However, after deleting that "*.bakk" registry entry, the VSS service has produced no more error messages - yet the error message from the VMware Converter remains the same, blaming VSS.
It's not inspiring that multiple other people online seem to have given up on this one. (e.g.)
I also report with disappointment that this was not my first unfavourable experience with this supposedly easy physical-to-virtual conversion tool. About a week ago I converted a Surface Pro 2 (Windows 8.1) physical to virtual prior to sending it in for servicing. I also had a lot of trouble then, although finally managed to get it to work. Two bad experiences out of two attempts. Relatively useless documentation. Sadly, this is my experience of VMware so far : It is awesome when it works, and an extreme pain when it doesn't, which is far too often.
VMware Fusion PC Migration Assistant requires HFS
The skinny :
The VMware Fusion PC Migration Assistant must have an HFS-formatted drive as the destination for the physical-to-virtual conversion.
The fat :
Thanks VMware for the helpful error messages - not!
Here's the error message I got trying to convert a four-and-a-half-year-old laptop to a virtual machine :
"VMware Fusion was unable to share a folder to receive your migrated pc"
Hmmm.
Retry.
Same problem.
Google.
An obtuse comment, which leads me to suspect... voila!
I was trying to convert the physical machine into a virtual machine on an exFAT drive.
Try again, converting it to an HFS drive for later copying to the exFAT destination - problem solved!
The VMware Fusion PC Migration Assistant must have an HFS-formatted drive as the destination for the physical-to-virtual conversion.
The fat :
Thanks VMware for the helpful error messages - not!
Here's the error message I got trying to convert a four-and-a-half-year-old laptop to a virtual machine :
"VMware Fusion was unable to share a folder to receive your migrated pc"
Hmmm.
Retry.
Same problem.
Google.
An obtuse comment, which leads me to suspect... voila!
I was trying to convert the physical machine into a virtual machine on an exFAT drive.
Try again, converting it to an HFS drive for later copying to the exFAT destination - problem solved!
Friday, July 11, 2014
VMware Fusion on exFAT
The skinny :
VMware Fusion wastes 30 seconds of your life accomplishing apparently absolutely nothing every time you start or resume-from-disk a virtual machine on an exFAT volume.
There appears to be no workaround.
The fat :
I love virtualization. And the more I use it, the more I love it.
It has come a long way.
I remember 12 years ago giving up in frustration when I tried to virtualize my entire software development environment.
The big issue back then was the storage system.
Now with so many so-awesome SSDs to choose from, virtualization is a pleasure.
I'm running my virtualized software development environment with I'd guess about a 10-20% performance penalty, vs the literally 200-2000% performance penalty I was experiencing 12 years ago.
And since computers are generally so fast these days, 10-20% performance penalty largely translates into no significant difference at all.
Mac & PC
I happen to be a dual-mode man. Surface Pro 2 256GB (love it!), and Mac Mini quad-core i7 16GB RAM. I mainly do Windows stuff, and prefer the more extensive range of keyboard shortcuts in Windows for maximum productivity (whereas with Mac you are forced to keep moving your hand back to the mouse/trackpad whether you like it or not). But I'm very comfortable and proficient in both environments.
I wonder, could I... Get an external SSD and put my virtual machines on it. Then, using VMware Fusion on the Mac and VMware Player or Workstation in Windows, I can run my virtual machines on the faster more powerful Mac Mini when inside, whilst still being able to take my work on the road and run exactly the same VMs on the Surface Pro 2.
Great idea!
But so many snags.
First off, you are going to encrypt that external SSD, right? I mean, nobody puts sensitive data on an unencrypted external storage device I hope? (Other than government departments of course - but who expects competence from them?)
Problemo : Windows has BitLocker, and Mac has FileVault, and ne'er the twain shall meet!
And whilst you can get cool third-party utilities to read+write Mac disk format from Windows, and likewise to read Windows disk format from Mac, none of these utilities support encrypted volumes. Major problem! Looks like we're scuttled right at the git go!
Well, there is TrueCrypt of course. It's discontinued, there are question marks over its actual security level, and it's open-source, which leaves one wondering whether it might just go ahead and destroy all your data mysteriously and irrecoverably due to some strange previously-unencountered bug (or worse yet a known bug that has been languishing in the support queue for years, as happens sometimes with open-source and even commercial products).
But, TrueCrypt appears to be the only strong contender. After all, we need something cross-platform, and that alone rules out a bunch of options. And whilst performance and reliability have to be assessed, we do know that TrueCrypt has zillions of users, so we take the punt that it'll do the job well - of course making regular VM backups just in case.
Next snag : Filesystem? I end up opting for exFAT, because it is natively supported in read+write mode by both Windows and OS/X.
Score! My VMs run fast, and yes, I can transfer the external SSD back & forth between Mac Mini and Surface Pro 2 and it all works!
At this point, I'm super-excited.
However, I'm bothered by something.
It seems that every time I build a VM on the Mac Mini, then run it on the SP2, then take it back to the Mac Mini, there is a strange 30 second delay at the very start of booting the VM.
I Google - no answers.
It's been frustrating me around a month now, but I finally found the answer.
It has nothing directly to do with whether the VM is in the "Shared Virtual Machines" vs "Virtual Machines" folder, and nothing directly to do with running the VM on the Windows host.
It seems to be wholly & solely the VM being on an exFAT volume.
I can take the VM that has the 30 second delay at the very start of the boot process, copy it to a native Mac partition, and it boots immediately without the 30 second delay.
I tried some configuration tweaks that seemed unlikely to help, and indeed they didn't help.
My conclusion? Lovely conceptually as it is to be able to share VMs twixt Mac & Windows via this external SSD, it's proving all told a little on the painful side. Not hugely painful, but having to connect the SSD, run TrueCrypt, mount the TrueCrypt volume, use VMs, unmount the TrueCrypt volume, unmount the SSD - that's a little tedious - and now add that there is an absolute waste of 30 seconds of your life at the very outset of every VM boot (and I tend to be starting & stopping VMs a lot throughout the day), and it gets a little frustrating.
The VMs once running run just fine, so it's clearly something VMware could fix.
But I found no-one else anywhere else mentioning the same problem, so I doubt it's even on VMware's radar.
I'll stick with the system for now - it does work - but I'm thinking of changing to a setup where both the Mac and the SP2 have a full copy of all VMs, on their native filesystems with their native full-disk-encryption technologies, and using any of the zillions of backup / file-replication utilities out there so that when I run the VM on one and shut it down, any changes get copied across to the other copy of the same VM. If that works, then I'll have a truly blissful and hassle-free experience of using the same VMs on two different machines, one being an OS/X host and the other being a Windows host.
The big problem then will simply be storage space disparity. I might end up paying the small fortune to get a 512GB Surface Pro 2 or 3, just so I can fit everything. Or else I might use an external SSD just for the less-frequently-used VMs. Or I might augment the SP2's storage with an external SSD encrypted with BitLocker and formatted with NTFS and used only by the SP2.
The short of it? VMware Fusion runs VMs off exFAT partitions just fine, but for no apparent reason will waste 30 seconds of your life every time you boot a VM, at the very start of the boot process, before even the VMware Fusion logo pops up on the VM screen. Please fix it, VMware!
P.S. The problem does not occur with VMware Workstation / Player - i.e. on the Windows host, the 30 second boot delay does not occur. It is only a problem with VMware Fusion.
P.P.S. I'm using VMware Fusion 6 Professional (paid) and VMware Workstation 10 (trial), about to change to the latter being VMware Player Plus (using the VMware Player Plus license that comes free with VMware Fusion 6 Professional).
VMware Fusion wastes 30 seconds of your life accomplishing apparently absolutely nothing every time you start or resume-from-disk a virtual machine on an exFAT volume.
There appears to be no workaround.
The fat :
I love virtualization. And the more I use it, the more I love it.
It has come a long way.
I remember 12 years ago giving up in frustration when I tried to virtualize my entire software development environment.
The big issue back then was the storage system.
Now with so many so-awesome SSDs to choose from, virtualization is a pleasure.
I'm running my virtualized software development environment with I'd guess about a 10-20% performance penalty, vs the literally 200-2000% performance penalty I was experiencing 12 years ago.
And since computers are generally so fast these days, 10-20% performance penalty largely translates into no significant difference at all.
Mac & PC
I happen to be a dual-mode man. Surface Pro 2 256GB (love it!), and Mac Mini quad-core i7 16GB RAM. I mainly do Windows stuff, and prefer the more extensive range of keyboard shortcuts in Windows for maximum productivity (whereas with Mac you are forced to keep moving your hand back to the mouse/trackpad whether you like it or not). But I'm very comfortable and proficient in both environments.
I wonder, could I... Get an external SSD and put my virtual machines on it. Then, using VMware Fusion on the Mac and VMware Player or Workstation in Windows, I can run my virtual machines on the faster more powerful Mac Mini when inside, whilst still being able to take my work on the road and run exactly the same VMs on the Surface Pro 2.
Great idea!
But so many snags.
First off, you are going to encrypt that external SSD, right? I mean, nobody puts sensitive data on an unencrypted external storage device I hope? (Other than government departments of course - but who expects competence from them?)
Problemo : Windows has BitLocker, and Mac has FileVault, and ne'er the twain shall meet!
And whilst you can get cool third-party utilities to read+write Mac disk format from Windows, and likewise to read Windows disk format from Mac, none of these utilities support encrypted volumes. Major problem! Looks like we're scuttled right at the git go!
Well, there is TrueCrypt of course. It's discontinued, there are question marks over its actual security level, and it's open-source, which leaves one wondering whether it might just go ahead and destroy all your data mysteriously and irrecoverably due to some strange previously-unencountered bug (or worse yet a known bug that has been languishing in the support queue for years, as happens sometimes with open-source and even commercial products).
But, TrueCrypt appears to be the only strong contender. After all, we need something cross-platform, and that alone rules out a bunch of options. And whilst performance and reliability have to be assessed, we do know that TrueCrypt has zillions of users, so we take the punt that it'll do the job well - of course making regular VM backups just in case.
Next snag : Filesystem? I end up opting for exFAT, because it is natively supported in read+write mode by both Windows and OS/X.
Score! My VMs run fast, and yes, I can transfer the external SSD back & forth between Mac Mini and Surface Pro 2 and it all works!
At this point, I'm super-excited.
However, I'm bothered by something.
It seems that every time I build a VM on the Mac Mini, then run it on the SP2, then take it back to the Mac Mini, there is a strange 30 second delay at the very start of booting the VM.
I Google - no answers.
It's been frustrating me around a month now, but I finally found the answer.
It has nothing directly to do with whether the VM is in the "Shared Virtual Machines" vs "Virtual Machines" folder, and nothing directly to do with running the VM on the Windows host.
It seems to be wholly & solely the VM being on an exFAT volume.
I can take the VM that has the 30 second delay at the very start of the boot process, copy it to a native Mac partition, and it boots immediately without the 30 second delay.
I tried some configuration tweaks that seemed unlikely to help, and indeed they didn't help.
My conclusion? Lovely conceptually as it is to be able to share VMs twixt Mac & Windows via this external SSD, it's proving all told a little on the painful side. Not hugely painful, but having to connect the SSD, run TrueCrypt, mount the TrueCrypt volume, use VMs, unmount the TrueCrypt volume, unmount the SSD - that's a little tedious - and now add that there is an absolute waste of 30 seconds of your life at the very outset of every VM boot (and I tend to be starting & stopping VMs a lot throughout the day), and it gets a little frustrating.
The VMs once running run just fine, so it's clearly something VMware could fix.
But I found no-one else anywhere else mentioning the same problem, so I doubt it's even on VMware's radar.
I'll stick with the system for now - it does work - but I'm thinking of changing to a setup where both the Mac and the SP2 have a full copy of all VMs, on their native filesystems with their native full-disk-encryption technologies, and using any of the zillions of backup / file-replication utilities out there so that when I run the VM on one and shut it down, any changes get copied across to the other copy of the same VM. If that works, then I'll have a truly blissful and hassle-free experience of using the same VMs on two different machines, one being an OS/X host and the other being a Windows host.
The big problem then will simply be storage space disparity. I might end up paying the small fortune to get a 512GB Surface Pro 2 or 3, just so I can fit everything. Or else I might use an external SSD just for the less-frequently-used VMs. Or I might augment the SP2's storage with an external SSD encrypted with BitLocker and formatted with NTFS and used only by the SP2.
The short of it? VMware Fusion runs VMs off exFAT partitions just fine, but for no apparent reason will waste 30 seconds of your life every time you boot a VM, at the very start of the boot process, before even the VMware Fusion logo pops up on the VM screen. Please fix it, VMware!
P.S. The problem does not occur with VMware Workstation / Player - i.e. on the Windows host, the 30 second boot delay does not occur. It is only a problem with VMware Fusion.
P.P.S. I'm using VMware Fusion 6 Professional (paid) and VMware Workstation 10 (trial), about to change to the latter being VMware Player Plus (using the VMware Player Plus license that comes free with VMware Fusion 6 Professional).
Subscribe to:
Posts (Atom)