I recently switched from a big honkin’ Dell XPS ‘gaming’ desktop computer to an iMac with additional Thunderbolt monitor as my home rig.  I added a G-Technology G-Speed Studio 12TB (9 usable under RAID 5) external storage array to store all my crap from the Dell.  This is a very kick ass Thunderbolt-based disk array by the way; $2200 on Amazon currently: http://amzn.to/1BT3fzw

I buy a nice copy of VMware Fusion Pro 7 for Mac with the intent of virtualizing my old desktop since it still has some apps on it that I need, like Visio (WTF, can someone please develop a true Visio equivalent for Mac?).  I want a true byte by byte image of my old Windows 7 system so all my metadata (drive perms, ownership, etc) is preserved.  This meant using the VMware vCenter Converter to P2V it instead of the Fusion PC Migration thing.

I set up an SMB file share on my Mac mapped to my Fusion Virtual Machines folder on my RAID array.  I map a drive to it from the Windows 7 box.  I drag and drop about 20 gigs worth of files on the PC to the Mac since I wanted them native on the Mac anyway and I don’t plan to use Fusion’s folder sharing features; those came over nice and fast, no issues.  Okay, the moment of truth, I fire up the vCenter Converter, select convert online machine, select local machine, accept the default options, hit Go.

Things are cruising along for a few minutes until I hit 5% and then I get this ugly error:

FAILED: An error occurred during the conversion: 'BlockLevelVolumeCloneMgr::CloneVolume: Detected a write error during the cloning of volume \WindowsBitmapDriverVolumeId=[00-00-00-E8-00-00-50-06-00-00-00-00]. Error: 209 (type: 1, code: 13)'

Digging around all over the internet for vmware-related converter failures, I find a TON of threads referencing bad blocks on the source side as being the cause of those.  The general consensus is run a repair-enabled chkdsk command, reboot since it can’t do its things while the OS is running, run GUI-based, then run GUI-based disk defrag.  I waste hours jumping through all of those hoops with no errors reported or repaired by the utilities.

Try again, no bueno.  I find more posts online suggesting vCenter Converter sometimes screws up if you try to P2V a system with multiple drives, whether physical or logical.  The suggestion in that case is do one conversion with the system volume, then another with the “C” drive and another for each additional drive that is mounted.  After completion, you put all the vmdk’s back together in one folder and map them as additional drives into the initially converted machine before booting it up.  I give that a try, and I get the same failure on even the standard system volume.

So I start digging into the logs the converter produces; they’re really just more verbose versions of what I already saw in the GUI.  This one is converter-gui-8.log for example:

--> mostRecentError = (converter.fault.CloneFault) {
--> faultCause = (vmodl.MethodFault) null,
--> description = "BlockLevelVolumeCloneMgr::CloneVolume: Detected a write error during the cloning of volume \WindowsBitmapDriverVolumeId=[00-00-00-E8-00-00-50-06-00-00-00-00]. Error: 209 (type: 1, code: 13)",
--> msg = "An error occurred during the conversion: 'BlockLevelVolumeCloneMgr::CloneVolume: Detected a write error during the cloning of volume \WindowsBitmapDriverVolumeId=[00-00-00-E8-00-00-50-06-00-00-00-00]. Error: 209 (type: 1, code: 13)'"
--> },

Where I finally find something useful is in the zip file within the zip file named worker-diagnostics-task-1-rkc.zip, in a file called vmware-converter-worker-2.log:

2015-06-26T09:53:26.313-04:00 info vmware-converter-worker[05368] [Originator@6876 sub=Default] Sysimgbase_DiskLib_Write failed with 'There is not enough space on the file system for the selected operation' (error code:13)
2015-06-26T09:53:26.314-04:00 error vmware-converter-worker[05368] [Originator@6876 sub=task-2] TargetVolumeWriter::WriteToVolume(): Error (type: 1, code: 13) writing 655360 bytes to the destination volume at offset 0x000000072db88000

Oooh, interesting, “‘There is not enough space on the file system for the selected operation’ (error code:13)“.  Well how is that possible?  My RAID array is nearly empty, so there’s almost 9 TB available and I’m only trying to P2V a 1 TB drive to it.  I start digging around online and find some fairly old threads about the MacOS SMB service having a 2 gig file size limit, but that was in the 10.5 era when they bundled Samba without large file extensions, and supposedly that issue had been resolved long ago.  Additionally, a couple files in that initial Windows 7 to Mac SMB share copy I did were larger than 2 gig, so I didn’t think that was the issue.  I mess with perms, trying to give back world writable access to the share after setting it up, to the converter files after they start getting written, etc., but the same failure occurs at the same point each time.  So who knows, maybe there still is some weird restriction on file size and when the converter tried to tell the Mac to allocate that 1 TB of space, it barfed.

In any case, after wasting hours trying to do this, I hooked a 2 TB USB drive to the Windows system a few hours ago and started converter, and now we’re at 13% with a 104 GB vmdk so far.  All previous attempts with the MacOS SMB share died at 5%, so I think this one will be successful, just sucks waiting for 1 TB of data to write to a slow USB hard drive.

Hopefully this helps someone not waste a ton of time trying to P2V with a MacOS SMB share as the target, since it apparently won’t work.