Zahir: this looks like a problem with the disk
layout, not anything to do with 64 bit. I don't
think Solaris guests are currently supported by
VMware Converter. Disk type changes are
particularly problematic, since they require updates
to device configuration data within the
guest OS.
Thinking about this some more, I think this argument is frankly specious. If you follow the link to how I resolved this problem you can see that Converter could have used the /devices path and thus not have had to deal with device reconfiguration - all that does is to create the legacy /dev path links but the /devices path relies entirely on bus topology and that's known at conversion time.
It's ugly, which is why humans don't use the /devices paths in vfstab but it's perfectly valid to do so and the user can clean that up later after reconfiguration has occurred to use the "nicer" /dev/dsk and /dev/rdsk paths. If Converter wanted to be extremely nice to Solaris users it could drop an RC script in one of the later boot phases to do the vfstab cleanup once after reconfig (and then remove itself). It seems like Converter is doing 95% of what Solaris users need, and could be made to do the remaining 5% (which many users will struggle with - those /devices paths are tough to type correctly).
Please consider enhancing Converter to deal with Solaris better. You have a great product here but it could be easier to use. While you're at it, please make Converter deliver better error messages. I usually got "unknown error, see the logs", and the real error was buried in the log (typically an absolute pathname to the vmdk file, while I was importing the directory via a Samba share so the absolute path couldn't be resolved. This wouldn't have been a problem if VMware Server had used a relative pathname rather than an absolute one when it created the VM).
In summary - my 3 enhancement requests:
1 Converter: update bootparms.rc and vfstab using the /devices pathnames
2 Converter: reflect the errors better from the logs
3 Server: use relative pathnames in the vmx file, to make future conversions easier from exported filesystems
OK - two more biggies:
Make both VI Client and Converter runnable from within the COS! That would be huge, and save having to set up a Windows host for these purposes, complete with licensing costs. I wound up creating an XP guest VM (and enabled Remote Terminal Services so I could access it via RDP) just for this purpose, and I'm sure I'm in good company.
Thanks!
Message was edited by:
radman
