I thought, "must have to delete the current one & then add the new one - reasonable enough...".
Well, in the VMware GSX document I pointed you to, it was said explicitely that you can retain the old disk, change to the new disk and if it's working, then delete the old one. Bah, documentation 
Neither are particularly satisfactory as far as I'm concerned as in 1) the file is not moved under the new VM, it is retained in it's current location and so, you cannot delete the old VM as the file is part of its package. (& that's another issue - I don't think .vmdk files should be part of a package - it's too inflexible). With 2) a user shouldn't have to go poking around in an application package to do something pretty fundamental (IMO) functionality-wise. That should be part of the gui. As should deleting a VM. & .vmdk files. Pretty fundamental stuff.
I agree over-intelligent GUIs can make things hard. That's why I usually prefer command-line. You could simply add the disk directly to the .vmx file. But be realistic about your very current problem instance - you have 2 options:
Wait until the GUI in Fusion can do this
Do the "dirty" solution of editing .vmx file which works
The lines for the SCSI disk in my case are like this (hope you are using SCSI, not an IDE disk - SCSI is default one on XP, Vista new virtual machine):
scsi0:0.present = "TRUE"
scsi0:0.fileName = "Windows XP Professional.vmdk"
And if you don't have the following lines, add them as well (not sure what the "redo" option does, but it is to be in my file and in an example on the site linked below):
scsi0.present = "TRUE"
scsi0:0.redo = ""
scsi0.pciSlotNumber = "16"
More about SCSI disk .vmx parameters on a dedicated site, in case you want to know what each of that option means.
But I have to say I had never done editing .vmx file manually (but from what I heard, editing .vmx file is a common practice for solving some peculiar problems like yours).
Other option would be add a disk of some different name (and make sure it's SCSI again if your original disk was SCSI), hit "Apply", close Fusion, then open terminal, change to the appropriate .vmwarevm directory, move the converted disk over the file just created by fusion when adding a new disk (i.e. mv converted-disk.vmdk the-disk-name-that-was-in-the-gui-when-you-just-added-it-and-hit-apply.vmdk). Then start the machine.
Choice is yours (to wait for a guaranteed answer from some .vmx file guru who knows for sure the answer I provided above is OK is also an option).
>...
Well, in the VMware GSX document I pointed you to, it was said explicitely that you can retain the old disk, change to the new disk and if it's working, then delete the old one. Bah, documentation
I admit I didn't look at that documentation. However, I just did so and there was nothing there to indicate how I would check whether the new disk was working (in the GUI). Remember that trying to 'add' the (existing) new/converted disk doesn't work. I suppose that the re-name facility (-n) might work 'tho.
>...But be realistic about your very current problem instance - you have 2 options:
Wait until the GUI in Fusion can do this
Do the "dirty" solution of editing .vmx file which works
Well sure, you do what you gotta do, but my point is that you shouldn't have to.
>...
Other option would be add a disk of some different name (and make sure it's SCSI again if your original disk was SCSI), hit "Apply", close Fusion, then open terminal, change to the appropriate .vmwarevm directory, move the converted disk over the file just created
by fusion when adding a new disk (i.e. mv converted-disk.vmdk the-disk-name-that-was-in-the-gui-when-you-just-added-it-and-hit-apply.vmdk). Then start the machine.
Sure - effectively doing a rename.
I've since learnt (embarrassingly) that this whole exercise was probably unnecessary, as the destination program for the .vmdk files seems to accept segmented .vmdk files! (Recognizes it, but doesn't boot 'tho 
) But - it was good to find out about this for when I really
do need to change .vmdk files for a machine.
Choice is yours (to wait for a guaranteed answer from some .vmx file guru who knows for sure the answer I provided above is OK is also an option).
Think that it is ok (according to eTung).
Thanks,
GAM
(& that's another issue - I don't think .vmdk files should be part of a package - it's too inflexible)
What would you suggest? The current idea is that with a default setup, everything you need is in the .vmwarevm bundle; beginners shouldn't have to worry about "well, did I copy or back up all the files I needed?" You can certainly create a virtual machine with
outside references, but the hope is that people who do that know what they're doing.
I understand that, but I think you should give people a choice to do something different from the default. How would you create a VM with outside references without a pre-existing .vmdk file? I'd present a standard file creation dialog box which is initially pointing within
the package (default) but then allowing the user to navigate away somewhere else.
>..
The idea is that virtual machines are (large) documents, so you delete them via the Finder, just like any other document.
The fact that they are so large makes it inappropriate (IMO) to treat them as documents. I mean - they are an order of magnitude larger than a movie file. They represent disks. I suppose you did think about the impact on backups to put those files under the user's
home directory too? Again - I can see what you intended here, but I think they are very different to documents and having Fusion being the 'control centre' for VMs and their associated disks is a lot more sensible/intuitive than having Word coordinate .doc files.
>...On the other hand, (the thinking was that) changing .vmdk files around is not a common task a beginner would need to do, so it was not as high a priority for the initial releases.
Another way of looking at that is that if it was in the gui, it would facilitate less experienced users more easily doing it. Changing disks between systems is one of the great advantages of virtual machines. I'm not that experienced and I wanted to do it. The fact that I've
since found out I may not have needed to is another matter... 
Regarding Boris' comment, I would say that it's not a case of the GUI being too intelligent, it's a case of the GUI not having enough options.
>...
Yes - I wondered about that too & I agree. This functionality exists, it's not hacking by any means, and so it should be able to be done in the gui. Guide users by all means with defaults, but provide them with the means to also change them if they so wish.
Thanks,
GAM