VMs constantly asking if I Copied or Moved VM

[VMware Community Member]

Starting about a month ago, everytime that I launch a VM I get a popup asking if i Moved or copied the Virtual machine.

This happens if the VM is suspended or turned off.  It happens on every VM that I have.

I am running an i9 MacBook Pro running macOS Sonoma

Any suggestions on how to fix this?

[ColoradoMarmot]

You are running the VM from different places each time, that's what causes it.  How are you launching them and where are they stored?

 

[VMware Community Member]

The VM's have been in the same location for years in ~/Documents/Virtual Machines.

I am launching them from the Virtual Vachine Library just as I have always done.  

The VMs have not beeen moved, or copied.  

I even tried to create a new VM and I get the same alert when I launched it after it was created.

 

 

[ColoradoMarmot]

Hmm, so couple of ideas:;

1) is this a new machine you migrated from?

2) Try launching by double clicking in finder instead of the library

3) make sure you’re using an administrator account

4) make sure it’s not a case sensitive file system.

[VMware Community Member]

Hi there,  

This is really frustrating and perplexing...

 

1) I am using a 2019 MacBook Pro that i have had since 2020, and several of the VMs have been on here since then, others have been created over the years and never had this issue until about a month ago.

2)  If I double click or launch from the VM library I get the alert.

3) Yes I only use admin accounts

4) Standard APFS volume group..

 

Any other suggestions?

[dempson]

Do you perhaps have any cloud file services enabled which might be relocating your Documents folder? The most likely candidate is iCloud Drive with the "Desktop & Documents Folder" option enabled. That is very bad for a VM.

The best way to manage VMs on recent macOS versions is to set up a separate volume inside the same APFS container as your main volume (so they can share free space), then move the entire Virtual Machines folders there and reopen each VMs in VMware Fusion (telling it you moved them). Tell Time Machine not to back up the volume which has the VMs.

This arrangement means that when Time Machine makes a snapshot on your main volume, it will not include your VMs and potentially waste a large amount of free space due to changes in the VM over the lifespan of those snapshots (which can persist for a while in some cases).

[Michael Roy]

I was going to comment and suggest this as well.

Newer versions of Fusion create "~/Virtual Machines" instead of "~/Documents/Virtual Machines/" for this very reason.

VMs are just fancy Documents from our perspective, but Apple decided that Documents means small text files that should be cloud sync'd, and it causes problems like this and others when we have VMs in those sync'd folders.

 

[ColoradoMarmot]

Great catch - the cloud sync is one of the most brain-dead features (it completely destroyed by documents folder when I accidentally turned it on - without any confirmation.)

[VMware Community Member]

Moving the VMs to a seperate APFS volume didnt help, neither did moving them to ~/Virtual Macines.  In both scenarios, I expected to get the prompt the 1st time that I launched the VM's after I moved t but not on subsequent launches.

I dont have any cloud services enabled for files.  The folder that the VMs are in are listed as an exemption in Time Machine, as well as in Spotlight and my AntiVirus software.

I have tried deleting the prefs, as well as the vmInventory file that is located in ~/Library/Application Support/ VMware Fusion.

I even went as far as fully deleting VMware Fusion and resinsralling, but that did not help either.

I verified that the permissions are correct on all the VM files.

Only thing that I could think of is that I updated macOS Sonoma to 14.2.1 just before this started.  I am currentky on 14.3, and still having the issue.

I searched the web extensively to see if anyone else had this issue, but couldn't find anything.  I dont have any other machines that can run Sonoma to see if its an OS issue,  I do not have this issue on my Macs that are running macOS Ventura.

[Technogeezer]

Can you disable your AV software and see if the problem still exists? 
What AV are you running?

[VMware Community Member]

I use BitDefender AV.  The problem even exists if I uninstall BitDefender.

[Technogeezer]

---

I verified that the permissions are correct on all the VM files.

Only thing that I could think of is that I updated macOS Sonoma to 14.2.1 just before this started.  I am currentky on 14.3, and still having the issue.

---

What versions of Fusion and macOS did you upgrade from?

Did you verify the permissions of the files contained in the .vmwarevm bundle, not just the permissions of the bundle itself?

Can you drop into the Terminal and post a listing of the contents of the .vmwarevm bundle, obtained with:

ls -ale@R path-to-virtualmachine.vmwarevm

Also, could you power on the VM, answer the questions about moved/copied, shut down the VM, then zip up and post both vmware.log and vmware.-0.log files found in the virtual machine's bundle folder?

 

[VMware Community Member]

I am enclosing the terminal output and the logs in the zipped file.

Hopefully they will give you some info as to what is going on.

Attachment(s)

Logs.zip   62 KB 1 version

[ColoradoMarmot]

Very odd.

It's not on a case sensitive file system by chance is it?  Or a fusion drive?

[VMware Community Member]

As I said in an earlier post, its a 2019 MacBook Pro.  the SSD is standard APFS.

And, yes, very odd.   And frustrating...

[Technogeezer]

How have you been answering the "copied vs moved" question?

Do you happen to have another VM in the virtual machine library that has the same MAC address for its virtual NIC as the one that's continually reporting the issues?

 

[VMware Community Member]

Hi Paul,

I have been selecting Moved.  On the Mac and Linux VMs I have tried Copied, but that did not make a difference.

I have checked all of the MAC addresses, and they are all different.

Also something that I noticed since I started the thread is that if i launch a VM, quit and relaunch it within an hour or so,  I don't get the alert.  its only after a couple of hours that the VM is off that I get the alert, which is making this even more confusing.

Usually I would not launch a VM so frequently that I did not notice this behavior.

If I Restart my MacBook, run Time Machine the VM still needs some time before I get the alert again.   I have nothing running in the background that would scan files or modify them on any schedule.  Nor, have I added anything new since this issue started.

[Technogeezer]

This is indeed bizarre, and smells of something mucking around with files associated with your virtual machine behind your back.

What else is running on that Mac besides Fusion? Could you provide a quick support data collection bundle  (Help > Collect Support Information... > Quick) and post it?

[VMware Community Member]

Here is the report that it collected.

Attachment(s)

VMware Fusion Quick Problem Report 2024-01-27 at 17.13.55...13   14.06 MB 1 version

[Technogeezer]

One really glaring problem from the logs.

You are running with System Integrity Protection (SIP) disabled. Before doing anything else, Enable SIP. If you're running software that's requiring you to run with SIP disabled stop using it and look for an alternative. Vmware is not designed or tested to run on  configurations that have SIP disabled.

Because of the number of third party background items you are running (including Cocktail, Carbon Copy Cloner,  Alfred, SoftRAID, DropBox, TechToolPro), I'd try booting the Mac into Safe Mode and then seeing if the problems recur.

If you don't want to do that, scrupulously check all the settings of everything you have that looks, walks, or quacks like a background task to see how it's configured and what it's touching. Particular attention needs to be paid to utility software (Like Cocktail, Tech Tool Pro, App Delete, Intel Power Gadget) and any of the myriad of the Finder "enhancers" that you're running) to see if they're running scheduled activities, and what on earth they may be doing to your system. It's been my experience that a lot of these "helpful" tools are not "helpful" at all because they are hacking the system in ways that are totally unpredictable and don't provide auditing of what they've done.

Things like "cleaners" such as Cocktail ane Onyx are particularly suspect as they are nothing more than placebos. They should be used ONLY when you have evidence of a problem that they can fix (which is rare). They typically can cause more problems than they solve. 

 

[VMware Community Member]

Hi Paul,

I know that its not an issue with SIP since that has been off forever. I have some tools that I need to use that require it to be off.

The one thing that I forgot about was that I installed SoftRaid on this Mac to setup an external RAID array about the time that this started.

I will uninstall that and see if it is the culprit as well as check other things that you mentioned.  

I will let you know what I find out.

[Technogeezer]

I don’t think that SoftRAID is the culprit. My guess is that one of the other “helpful” utilities is running on a scheduled basis and messing with something it shouldn’t. That’s why I recommended a boot to safe mode to get to a state that’s as close to a clean environment as possible to see if that’s the issue. It may not be easy to find the culprit in an environment with the number of add ons that you have running. 

[VMware Community Member]

Hi Paul,

I have been going through my system and removing a lot of utilities that may run in the background.

 

I tried to enable SIP, buut when enabled Fusion will not run,  I get the fillowing error.

Transport (VMDB) error -14: Pipe connection has been broke

I tried deleting Fusion and reinstalling. but kept on getting the message.

Disabling SIP allowed Fusion to run fine other than the alerts.

[Technogeezer]

---

 wrote:

Hi Paul,

I have been going through my system and removing a lot of utilities that may run in the background.

 

I tried to enable SIP, buut when enabled Fusion will not run,  I get the fillowing error.

Transport (VMDB) error -14: Pipe connection has been broke

I tried deleting Fusion and reinstalling. but kept on getting the message.

Disabling SIP allowed Fusion to run fine other than the alerts.

---

You have something else that’s been broken on your Mac if you get this message when running Fusion with SIP enabled. I’d put this problem on the  back burner and try to solve your original problem first.

I suspect one of two potential causes to this issue, both related to improper permissions or attributes being set on macOS files. 

[bluefirestorm]

Might be the statement of the obvious: the vmInventory file is zero bytes in size. So it is empty (hence the prompt appears for all VMs) and fails to write (and thus continues on asking). Why it is zero and failing to write is the likely the issue.

/Library/Application Support/VMware/VMware Fusion/Shared:
total 0
-rw-rw-rw- 1 kevin admin - 0 Jan 21 11:53 vmInventory

As a comparison, Fusion Pro 12.2.5 Pro on Monterrey the vmInventory is located on

/Library/Application Support/VMware Fusion/vmInventory with permissions as -rwxr-xr--

You could try to change the permissions and/or manually reconstruct one VM entry and see it if still prompts for that. I am too lazy right now to manually reconstruct one entry based on the macOS Catalina vmware.log in the other post.

Maybe just change the permissions with the same permissions as Monterrey. To reconstruct one entry (not manually), perhaps "Delete VM" from Library without moving it to Trash and then reopen from Library and run and see if the revised permissions results into at least vmInventory that is not zero bytes in size.

[VMware Community Member]

In Fusion 13.5 on Sonoma there are 2 vminventory files

One with 0 bytes in /Library/Application Support/VMware/VMware Fusion/Shared/.

There is another one that is 8,713 bytes (12 KB on disk) located in ~/Library/Application Support/VMware Fusion/ 

[bluefirestorm]

My understanding is that the VMinventory file is the reference file whether a VM is new to the host and thus results in the Moved or Copied prompt. Question now is whether is it looking at the same place? There is no ~/Library/Application Support/VMware/VMware Fusion/Shared on Fusion 12.2.5 on Monterrey.

So if "Copied it" was chosen a new uuid.bios value should be written in the vmx and rightfully it should also create a new entries in the VMinventory file (since it is supposed to be a new VM to the host).

Unless it is a different file altogether or maintained inside some plist now in version 13.5.x/Sonoma.

What if the ~8KB VMinventory file is copied over to ~/Library/Application Support/VMware/VMware Fusion/Shared?

[a_p_]

I tried to reproduce this, but it worked for me, so I went through all of the log files, and from my perspective, it looks like either a bug in Fusion, or a file permission/overwrite issue.

After the VM is started for the first time, Fusion detects a mismatch between the "uuid.location" in the VM's .vmx file and the entry in the vmInventory file. In this case, that's "vmlist6.UUID". After answering the Question moved/copied, a new UUID is generated and updated in the .vmx file, but not in the vmInventory (at least not written to disk).

What I think is that there's some kind of file caching, which causes that while powering on the VM again after a short time, the cached value is still valid (i.e. no UUID mismatch), and after some more time the vmInventory file with the old UUID is re-read, which causes the question to pop up again.

To troubleshoot this issue, you may:

1. check the VM's current UUID in the .vmx and the vmInventory file
2. power on the VM and answer the Question with I moved it
3. check the UUID in the two mentioned files again immediately after that
4. if you find the UUID updated to the new value (see vmware.log), check the vmInventory file again later, to see whether the UUID has been "reset" to the old one

André

[bluefirestorm]

Yes, Andre. You are correct it is the uuid.location in the vmx that determines whether it is new to the host and nothing to do with vmInventory file.

The strange thing though is that uuid.location is different in the vmware-0.log and vmware.log of the macOS Catalina VM sample log.

2024-01-27T04:59:06.586Z In(05) vmx UUID: Writing uuid.location value: '56 4d b6 22 91 d9 53 4f-4e b3 6e fd 59 d4 a6 0e'
2024-01-27T04:59:06.586Z No(00) vmx ConfigDB: Setting uuid.location = "56 4d b6 22 91 d9 53 4f-4e b3 6e fd 59 d4 a6 0e"

2024-01-27T19:38:23.646Z In(05) vmx UUID: Writing uuid.location value: '56 4d 08 56 5d f0 55 7c-52 92 1d 63 23 33 f9 72'
2024-01-27T19:38:23.646Z No(00) vmx ConfigDB: Setting uuid.location = "56 4d 08 56 5d f0 55 7c-52 92 1d 63 23 33 f9 72"

So is there some feature in Sonoma that randomises the hostname or computername or some other unique identifier for security obsfucation purposes? That in turn confuses Fusion that it is always running on a new host for the first time that causes it to generate a new UUID? If it was a file permission issue at the very least, the uuid.location should be the same (unless the permission issue is with how uuid.location value is retrieved/generated/determined).

[a_p_]

That's not ho I interpret this.

From how I understand it, Fusion creates a new UUID in case of a mismatch, but this new UUID does - for whatever reason - not get updated in the vmInventory file.

André

[bluefirestorm]

Sorry, I got myself confused.

Anyway, I agree to troubleshoot this is to check if the new uuid.location and uuid.bios values are updated in the vmInventory file. Although it might be easier to start with a blank inventory file (but I dangerously assume the uninstall/reinstall of Fusion should have wiped it out).

[Technogeezer]

---

 wrote:

Sorry, I got myself confused.

Anyway, I agree to troubleshoot this is to check if the new uuid.location and uuid.bios values are updated in the vmInventory file. Although it might be easier to start with a blank inventory file (but I dangerously assume the uninstall/reinstall of Fusion should have wiped it out).

---

That is a indeed a dangerous assumption. Uninstalling of Fusion by dragging the application to the trash won’t remove the vminventory file. Fusion doesn’t have a “proper” uninstaller that will remove the “auxiliary” files Fusion creates in /Library and the user’s Library folders. But a manual uninstall using the procedure in KB article https://kb.vmware.com/s/article/1017838 will remove these files. 

[Technogeezer]

---

 wrote:

Sorry, I got myself confused.

Anyway, I agree to troubleshoot this is to check if the new uuid.location and uuid.bios values are updated in the vmInventory file. Although it might be easier to start with a blank inventory file (but I dangerously assume the uninstall/reinstall of Fusion should have wiped it out).

---

An examination of the vmInventory file and the.vmx files provided in the logs shows that the vmlist*.UUID entries match the corresponding bios.uuid entry in the .vmx file. That appears to be normal (I checked it against my personal set of VMs). 

It's the calculation of the uuid.location on power-up that seems to be giving something that's not matching the uuid.location stored in the .vmx file.

I haven't seen this issue on a stock Ventura or Monterey system. 

It might be worthwhile to perform a clean macOS install with none of the add-ons on an external disk (yes, I know this is a pain for T2 equipped Macs) and boot from it, then see if the behavior can be reproduced. If it can't then add the "add-ons" back one-by-one to see what might have broken things.

On a side topic, for the situation where SIP was re-enabled and the VM gave the "broken pipe" message, can you post the vmware.log file that was generated for that situation?

Also, does this behavior exist if you try to run the VMs from a new user account? (seeing if this might be system-wide or unique to this user).

[VMware Community Member]

Lots of responses, and a lot of things I tried.

1. When I uninstalled Fusion using AppDelete, it deleted the all of the associiated files including the vminventory file. and I manually verified that all the other files in the KB article were removed as well.

 

2. After i reinstalled Fusion, when I added the VMs to the Virtual machine Library, Fusion recreated the vminventory file.

 

3. The UUIDs are the same in the vminventory file and the vmx file of the virtual machine, and I still get the alert. My guess is that the only time that these change is when I have selected Copied in the alert.

 

4. I moved the Virtual Machines folder to the desktop, created a new Virtual Machine folder in my home folder, and then put all of the machines back in that location.  This did not resolve the alerts.

 

5. I uninstalled my AV (BitDefender), and also SoftRaid and any other utility that may have had background processes., This did not resolve the issue either. 

 

6. When I boot into safe mode I am unable to launch any of the Virtual Machines.  I get the following error.

 

7. Since I removed a lot of utilities, I am enclosing a new Quick Problem Report.  Perhaps it may give someone more ideas where to look next.

 

Attachment(s)

VMware Fusion Quick Problem Report 2024-01-28 at 17.30.11...30   12.90 MB 1 version

[Technogeezer]

Could you also post the results of the following commands in Terminal:

ls -ald /tmp /private/tmp
ls -alR /tmp/vmware*

 

 

[VMware Community Member]

MB Pro:~ $ls -ald /tmp /private/tmp
drwxrwxrwt 15 root wheel 480 Jan 28 18:19 /private/tmp
lrwxr-xr-x@ 1 root wheel 11 Jan 12 00:19 /tmp -> private/tmp
MB Pro:~ $ls -alR /tmp/vmware*
total 0
drwx------ 3 kevin wheel 96 Jan 28 17:25 .
drwxrwxrwt 15 root wheel 480 Jan 28 18:19 ..
drwx------ 2 kevin wheel 64 Jan 28 17:53 mksctrl

/tmp/vmware-kevin/mksctrl:
total 0
drwx------ 2 kevin wheel 64 Jan 28 17:53 .
drwx------ 3 kevin wheel 96 Jan 28 17:25 ..

[Technogeezer]

Ok, nothing wrong there.

I'm running out of ideas short of booting to a clean macOS installation on another disk. leaving SIP on and then adding things back one-by-one. 

I'm wondering if upping the debugging output of the VM would help? Settings > Advanced > Troubleshooting > Hang/Crash or Performance? 

I see you're running with profiles installed via an MDM solution. Any idea if they are putting restrictions on applications?

Without knowing what exactly how Fusion is calculating the uuid.location value, it's not easy to say why we're seeing the uuid mismatch.  

[VMware Community Member]

Just an update...

 

I decided to enable SIP, then boot into Safe Boot, then reinstall macOS Sonoma.   It solved the issue of Fusion running with SIP enabled.  

 

After the install was complete, i launched several VMs and got the alerts, and selected Moved.  I haven't launched any of the VMs since last noght, so this was expected.  

 

I wont know for a few hours though it if reinstalling the OS with SIP enabled resolves the moved/copied alert.

 

I will keep you informed.  If I still get the alerts, I will reup the Quick Problem report with the crash/hang level enabled in troubleshooting.

[VMware Community Member]

Also, MDM has been running on my Mac for several years, well before the alert issue showed up. the MDM Profile is just setup for MFA at boot on my Mac.  No restrictions for software or permissions are enabled in the MDM.

[VMware Community Member]

After doing more debugging one thing that I noticed was that my IP address was constantly changing...

The reson for this is that every few hours the MAC address for my WiFi was randomly changing causing VMware to think that I was on a different computer.

I think that this is a bug in Sonoma on my MacBook Pro, and I will be working with Apple to resolve it.

[VMware Community Member]

Just an update...

Thanks everyone for your input.

 

The problem has been resolved with the help of Apple.

 

The culprit was the Windscribe VPN software that I had installed on my computer. They added a feature to the software that would randomly spoof the MAC address and it would rotate the spoofed address every few hours.

 

Even though the software was removed from my computer, it left a Privelidges Helper Tool that continued the behavior.

 

Now that my MAC address is no longer spoofed, Fusion no longer thinks that its been moved or copied to a new computer.

 

Again,  Thank you all for the help in working to identify the issue.

[Technogeezer]

Thanks for the update.

That certainly was one of the more unique behaviors, and a difficult one to pin down - I give you credit for sticking with it. to resolution.

[Jacob Moore]

Hmm I have this same problem but I don't have any kind of VPN or anything like that. I wonder if there is anything else that could also be causing this issue? 

[Ken Feldman]

I had this same problem, beginning with the update to Fusion v13.6.2.   Based on the conversations in this thread (thanks everyone!) it seems that the UUID's are being updated in ~/Library/Application Support/VMware Fusion/vmInventory but the check on VM start is being performed against /Library/Application Support/VMware/VMware Fusion/Shared/vmInventory.. 

The solution that worked for me was:

    cd /Library/Application\ Support/VMware/VMware\ Fusion/Shared
    mv vmInventory vmInventory.save 
    ln -s ~/Library/Application\ Support/VMware\ Fusion/vmInventory .

Now there is only one copy of vmInventory and Fusion is no longer asking the annoying moved or copied question on every start. 

[Technogeezer]

That's strange. The VMs that are listed in the /Library/Applications\ Support/VMware/VMware\ Fusion/Shared/vmInventory should be those considered "shared" by Fusion. Fusion considers shared VMs as those saved in the /Users/Shared folder according to the documentation. 

In my mind, there should be 2 vmInventory files. Your local one and the global one that's in /Library/Application\ Support/VMware\VMware Fusion/Shared/vmInventory. I would not think that a VM should appear in both the local vmInventory file and the global  file. 

if you don't have any VMs shared to the /Users/Shared folder, I'd try deleting /Library/Applications\ Support/VMware/VMware\ Fusion/Shared/vmInventory. It will be recreated the next time Fusion starts. 

------------------------------
- Paul (technogeezer)
------------------------------

[Daniel Simon]

YES!! This worked for me on Sequoia 15.3.1. Thank you so much, Ken!

[Rui Ribeiro]

Using Fusion in Sequoia, has had this move or copy irritating messages for months now.

Solution proposed here did not work for me, got two duplicate menus.

What really worked for me, after reading this thread, was:

      rm /Library/Application\ Support/VMware/VMware\ Fusion/Shared/vmInventory

[Daniel Saez Gijon]

Hi, this worked for me on Sequoia 15.5 and VMware Fusion 13.6.2. Thank very much, Ken!!!!