Move .vmdk out off .vmwarevm

[VimaUser]

Desktop hypervisor for Macs. Fusion 11.5.7.
Due to probs with capacity of storage the physical layer the instance administrator plans to relocate secondary yet big virtual drives to other physical volume. Virtual drive stores Win 10 boot partition.

I am going to remove .vmdk from guest machine, copy all splits of this vmdk to desired local storage (move operation at lager point of time, just to be secure from mistakes), then reattach it back to same vm. 

It is the dialog Fusion plots every time one attaches an existing vmdk to vm. Neither of options received in that dialog 
convince me in this particular case:
* option let's share it with the vm that created it once  - use-case does not foresee sharing
* take this virtual drive away from vm that uses it currently - it may be bound with effects I don't like
   nor I am aware of
* make a separate copy - a risk like in bullet above, e.g. vmdk copy gets placed within .vmdk.

AI proposes to modify vmdk path in vm config file then to double check if it suffices,
if needed attaching vmdk to vm using Fusion GUI which will land back in initial problem.

Terminating whole procedure with shared vmdk will have the disadvantage of established share of vmdk
but in this particular case nobody intends the vmdk to be shared.

[Technogeezer]

If you're doing this with the GUI, chosing the option "Share this virtual disk with the virtual machine that created it" might be the safest of the 3 options for adding an existing virtual disk to a VM. It will update the .fileName attribute for the given bus/device entry in the .vmx file for that virtual disk to represent the full path to the .vmdk descriptor file.

For example. Here's the test I ran. I deleted a second virtual disk from my VM, but retained the disk files.  I moved the second virtual disk from the VM bundle (the descriptor vmdk file plus all the other slice files associated with the virtual disk) to a folder /Volumes/Virtual Machines/Fusion/VMDK Test. I then re-added the second virtual disk and used the "Share this virtual disk" option. The result what that the only thing that changed in the .vmx file was the entry in the .vmx file for the virtual disk filename from:

nvme0:1.fileNane = "Virtual Disk 2.vmdk"

to

nvme0:1.fileNane = "/Volumes/Virtual Machines/Fusion/VMDK Test/Virtual Disk 2.vmdk"

The virtual disk worked fine. (just make sure that permissions of new folder that's going to contain the moved vmdk file allow the user to read and write to both the folder and the individual .vmdk files within the folder).

No other metadata within the .vmdk file was changed that I can see.

IMO the term "sharing" in the dialog isn't quite what you might think it is. It's not allowing multiple running VMs to use the same virtual disk at the same time. It's allowing you to define the same virtual disk to more than one VM,. The restriction is that you can only use it with one powered on VM at a time. Fusion will refuse to power on a virtual machine that has a virtual disk that it thinks is in use by another virtual machine. You will receive a "directory not empty" error message -- which if you dig into the logs you'll find that it has found a lock file for the virtual disk from another VM instance). 

Now, if you still have concerns about using this GUI method, then yes, you can manually edit the ..vmx file and change the xxxx.fileName attribute from the original relative path o the full path of the moved .vmdk file. It would look similar to what I did through the GUI. 

My suggestion would be to shut down the VM (power it off, don't suspend it) and make a copy of the entire VM's bundle to another disk device before doing any movement of virtual disks, configuration changes, or manual edits of .vmx file. 

Comment. I'd take any AI response as advice and not a authoritative response. The AI system that generated the proposal has never done this procedure. If you do decide to take AI advice, back up your VM before taking any actions that it proposes. 

------------------------------
Paul Rockwell (technogeezer)
vExpert 2026 (3x)
------------------------------

[VimaUser]

Thank you for your feedback and engagement in my current matter.
Concerning my use of AI please be ensured that I am completely on your side, therefore I not only consult AI but also am reaching out to VMWare experts.

So far I act only the GUI-level and consider pivoting to CLI if it should be additionally needed.

The move of that one vmdk out of .vmwmwarevm file got still not initiated.

The point is that as of time being the .vmdk is not shared and the vm administrator is not expected to have had enabled sharing intentionally.

The only pain is its size and the aim to move it to other storage. All other attributes of vm and this vmdk should keep as these are this minute. Vm user and administrator workflows should not change concerning this vm other aspects as this one particular vmdk storage.

vmdk is not shared between two or among a number of vms as of time being. The expectation is it to be in same form when relocation is completed.

In this particular case there is no need nor a desire to make the vmdk sharable between two vm's regardless if sharing vm runtime or out of runtime is meant.