All Posts

The last version of Fusion 12 (12.2.5) would accept a Fusion 13 license key. Unfortunately that version won't run on Catalina. To run on Catalina you need 12.1.x which does not accept the Fusion 13 license. If you have a paid Fusion Pro 13 or Player 13 license, you can log into your VMware account and downgrade it at the Customer Connect licensing portal.  However, a personal use license can't be downgraded. You'll need to use the following site to register for a Fusion 12 personal use license (it's not the same as the site you used to register for the Fusion 13 personal use license): https://customerconnect.vmware.com/en/evalcenter?p=fusion-player-personal  

@drcomrade wrote: The solution that actually worked for me was to down the following: 1. Quit VMWare.  2. System Preferences --> Notifications ---.> right click on VMWare, 'reset notifications'.  3. Double click on VMWare Fusion.app.  4. 'Don't allow' push notifications for VMWare.  This forces VMWare to ask for permission to send push notifications, including 'added items that can run in te background'. Granted, it does mean othe notifications for VMWare won't come through - but this seems like a reasonabel tradeoff.  I just tried it. It doesn't work. You'll get fooled into thinking it works if you quit then immediately re-launch Fusion.  Even without turning off Notifications for Fusion, if you shut it down and then immediately re-launch Fusion you will not see the message. If you shut down Fusion, wait a few minutes, and then re-launch it, the message does reappear.  Im almost 100% certain that it's macOS is throwing the notification, and not Fusion. macOS is doing what it's supposed to - warn you about anything putting background tasks/services in the systemwide folders. The warning is for security notification purposes, and that's not something you want suppressed.  And I believe there is some kind of timed check that macOS is doing on the LaunchDaemons and LaunchAgents folders in order to generate the notification.  VMware aggravates the notification proliferation by constantly adding and removing its background items to the system locations every time you start and stop Fusion. No other application I know of does that - they install them once. It is a design decision by VMware (a poor one IMO) that needs to be revisited in the light of macOS's new behaviors. It's up to VMware to change Fusion to fix the issue - probably best to use Apple's recommendations on how to manage background tasks. 

Believe the error message and reference https://kb.vmware.com/s/article/90364 Whatever you are doing with Packer to create the VM is specifying a lsiogic virtual SCSI adapter type that is not implemented by Fusion on Apple Silicon. It appears that only VMware’s pvscsi is implemented for virtual SCSI hard disk controllers. Change what you are doing to specify a NVMe hard disk type. That is the recommended disk type for virtual machines on Apple Silicon Macs and is supported by Debian. Debian does not look like they include the pvscsi driver submitted by VMware to the upstream Linux kernel and Fusion doesn’t support anything other than pvscsi.

The solution that actually worked for me was to down the following: 1. Quit VMWare.  2. System Preferences --> Notifications ---.> right click on VMWare, 'reset notifications'.  3. Double click on VMWare Fusion.app.  4. 'Don't allow' push notifications for VMWare.  This forces VMWare to ask for permission to send push notifications, including 'added items that can run in te background'. Granted, it does mean othe notifications for VMWare won't come through - but this seems like a reasonabel tradeoff.     

Same error here, but trying to get packer 1.9.4 & VMware fusion 13.5. on Apple M1 Silicon to build a debian 12.2 (arm64) VM. Packer VMware plugin version: "packer-plugin-vmware_v1.0.10_x5.0_darwin_arm64"   When manually starting up, I have no problems at all. Packer fails with the error: " "The device type "lsilogic" specified for "scsi0" is not supported by VMware Fusion 13.5.0."   Please look into this. Thanks in advance.     

Sorry for the late reply, I did test with acceleration off, but I also run into the same issue as you did. > I'm going to try this on.a physical Intel PC running Fedora 39 (good chance for me to upgrade) to see if things are any different. I have a AMD Workstation that runs Linux natively and I haven't run into this issue on that machine. I also installed and tested on VSCode on Asahi Linux (Fedora 38 remix), as a way to see if the issue might be due to the ARM64 Linux build of VSCode. However, I have not been able to reproduce the issue there either.

I got the file. I'll post the rebuilt vmx file as well as instructions in the morning -- it's approaching midnight here in the EST time zone. The one thing I suggest is to take a backup of the folder of this Windows 7 x64 VM so we can preserve it in the event that something goes horribly wrong (not likely but always better to be safe than sorry)....

I've tried VSCode and I think I'm seeing the same things as you do. The console is definitely wonky and laggy. I've tried it with X11, Wayland, 3D on and 3D off. Nothing hits me over the top of the head to help me figure out if this is VSCode, Fedora, or Fusion related.  I'm going to try this on.a physical Intel PC running Fedora 39 (good chance for me to upgrade) to see if things are any different.

> Does Fusion have full disk access? No, it didn't.  If it asked for it I probably denied it; I only give that out grudgingly  I wish app developers in general would do a better job of explaining why they want their entitlements.  I'll run with it on for a few days and see if that was it. Thanks!

VMware Workstation runs on a PC that contains an Intel or AMD CPU chip. The M1 chip is neither of those.  If what you need to run is a pre-built virtual machine that runs on Workstation, then you're out of luck. Virtual machines built on Intel or AMD systems will not run on Fusion on M1 Macs.  If on the other hand it's a Windows application you might be able to install Windows 11 ARM on a Fusion VM, and then run your application (which I'm assuming is written for x64 Intel PCs) on that VM using the Rosetta-like Intel translation that Microsoft built into Windows 11 ARM.  A little more explanation on what you're trying to run for your class will help us figure out what your alternatives are.

A screen shot of the file list.   And: . Windows 7 x64-s013.vmdk .. Windows 7 x64-s014.vmdk .DS_Store Windows 7 x64-s015.vmdk Windows 7 x64-06e43f69.vmem Windows 7 x64-s016.vmdk Windows 7 x64-06e43f69.vmem.lck Windows 7 x64-s017.vmdk Windows 7 x64-06e43f69.vmss Windows 7 x64-s018.vmdk Windows 7 x64-s001.vmdk Windows 7 x64-s019.vmdk Windows 7 x64-s002.vmdk Windows 7 x64-s020.vmdk Windows 7 x64-s003.vmdk Windows 7 x64-s021.vmdk Windows 7 x64-s004.vmdk Windows 7 x64.nvram Windows 7 x64-s005.vmdk Windows 7 x64.plist Windows 7 x64-s006.vmdk Windows 7 x64.vmdk Windows 7 x64-s007.vmdk appListCache Windows 7 x64-s008.vmdk screenshotsCache Windows 7 x64-s009.vmdk vmware-0.log Windows 7 x64-s010.vmdk vmware-1.log Windows 7 x64-s011.vmdk vmware-2.log Windows 7 x64-s012.vmdk vmware.log ./Windows 7 x64-06e43f69.vmem.lck: . .. M00807.lck ./appListCache: . .DS_Store appsToPublish launchMenu .. appData fixedItems recentDocuments ./appListCache/appData: . .. 0005cdf79cc4bac155bd930dbecf8418.appicon ... ffa83a26512705682c295cb019cf67b8.appinfo version ./appListCache/appsToPublish: . appsToPublish.menudata .. version ./appListCache/fixedItems: . fixedItems.menudata .. version ./appListCache/launchMenu: . launchMenu.menudata .. version ./appListCache/recentDocuments: . recentDocuments.menudata .. version ./screenshotsCache: . .. screenshot_0000.png  

The one with a vmx opened fine, and I was able to log into it. The other one did not open, and I got no error either. I will look at the original drive and see what I can find. That one was a rahter large folder, so it's possible it got borked on the copy. So far I have 2. I have a stack of hard drives to look at that probably have a few more VMS on them as well. (I hope) Thanks for your help. So, no .vmx, no go. Got it...

Glad you're making progress. A VM won't power up unless a .vmx file is in the bundle. One additional thought. Are there any files in that directory that's missing the .vmx file named vmware.log (or vmware-0.log, vmware-1.log, vmware-2.log). If so, it may be possible to re-create the .vmx file using the information in those files.  If one of those files are available, zip it up and post it here and I'll see if I can re-create the .vmx file for you.

@TakeTime wrote: This is an interesting message...   That message is normal if the virtual machine has not been configured in its Settings > Advanced to disable side channel mitigations. It only means that the virtual machine will run more slowly (but more securely) than if the VM has the mitigations turned off.