Accepted Solutions
I would not necessarily do first as suggested by the other reply in this thread and instead add the following line to the Virtual Machine's .vmx configuration file.
scsi0.virtualDev = "lsilogic"
This should resolve the error message you're getting without having to modify the .vmdk directly. Have a look at: Editing the .vmx file for your VMware Fusion virtual machine (1014782)
That said, if you want detailed recomendations based on the actual existing configuration then... To help figure out what is what, the best way to provide comprehensive diagnostic information is to use the "Collect Support Information" command from the VMware Fusion (menu bar) > Help > Collect Support Information and then attach the .tgz file it created on your Desktop to a reply post.
I would not necessarily do first as suggested by the other reply in this thread and instead add the following line to the Virtual Machine's .vmx configuration file.
scsi0.virtualDev = "lsilogic"
This should resolve the error message you're getting without having to modify the .vmdk directly. Have a look at: Editing the .vmx file for your VMware Fusion virtual machine (1014782)
That said, if you want detailed recomendations based on the actual existing configuration then... To help figure out what is what, the best way to provide comprehensive diagnostic information is to use the "Collect Support Information" command from the VMware Fusion (menu bar) > Help > Collect Support Information and then attach the .tgz file it created on your Desktop to a reply post.
While the steps in the KB are valid steps of one method to change the adapter type that KB doesn't rectify everything as the VM is presently configured. In other words if ttabi changes it to lsilogic instead of ide then the .vmx file will not need additional manual edits not covered this. The bottom line is I wanted to see the support bundle before making recommendations to modify the .vmdk as it is the more prudent course of action in cases such as this to have all the technical facts first! 
Using dd to extract and inject back the "# Disk DescriptorFile" section of the monolithicSparse .vmdk file after changing buslogic to lsilogic in TextEdit. If I was sitting in front of the system or doing a remote access session it would take me less then a minute to safely edit the monolithicSparse .vmdk file and not have to take all that time splitting the disk.
In a Terminal use the following syntax:
dd if=<vmdk_name>.vmdk of=ddf.txt bs=512 skip=1 count=2
open ddf.txt
dd conv=notrunc if=ddf.txt of=<vmdk_name>.vmdk bs=512 seek=1 count=2
Message was edited by: WoodyZ - Added dd syntax.
dd if=<vmdk_name>.vmdk of=ddf.txt bs=512 skip=1 count=2
open ddf.txt
dd conv=notrunc if=ddf.txt of=<vmdk_name>.vmdk bs=512 seek=1 count=2
Thanks . 
I need to do more research on that to have better understanding on it.
avanish wrote: I need to do more research on that to have better understanding on it.
The dd program is an extremely powerful and wonderful utility, however it can also be extremely dangerous if not used properly! In other words, never use it without having a known good backup!
ttabi wrote:
The .vmx file contains scsi0:0.fileName = "Fedora 16-0.vmdk" and this would need to be changed to ide0:0.fileName = "Fedora 16-0.vmdk" and additionally adding ide0:0.present = "TRUE" while setting scsi0:0.present = "FALSE".
I'm confused, because the VMX file already has those changes:
Looking at the Fedora 16.vmx file from the support bundle those changes are not there!
I'm convinced that the import process is just broken.
I throughly agree with you and personally would never use it! I use my own methods to to P2V and V2V and for me it's faster and easier then dealing with what seems like a half-baked product at times. (I'm referring to the converting/importing components not VMware Fusion pre se.)