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:
Mac OS X 10.5 Leopard Server, 10.6 Snow Leopard Server, 10.7 Lion client or server, 10.8 Mountain Lion client or server and 10.9 Mavericks client or server are fully supported on VMware Fusion while running on supported Apple hardware. VMware Does not support P2V for Mac OS X. Not all versions of Mac OS X are legally virtualizable! If you want to P2V then image the physical disk to a virtual disk, either directly or using a.dmg image. VMware vCenter Converter Standalone 6.1.1 works with ESXi 6.5, virtualizing Windows PCs/VMs for free Questions? Remember, this is not something that is supported by VMware, and it is a free product after all.
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:
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:
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.
Vcenter Converter Linux Machine
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:
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:
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.
Vcenter Converter Linux Machine
Vmware Vcenter Converter 5.5
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.
