dempson's Posts

The question of "snapshots" is a side issue to your primary question, and has nothing to do with whether you are using internal or external storage for VMs, but I'll expand on that point below. As I said earlier, you can store your VMs as a folder on any disk accessible to macOS which has read/write access, though I'd recommend a Mac-native file system (APFS or MacOS Extended) rather than cross-platform one (such as FAT32, ExFAT or something which requires third party drivers) for reliability reasons and to avoid complications with permissions, file naming, file size, etc, and it is better to use fast storage (with a fast enough interface) rather than something slow like an external hard drive. VMware doesn't care whether the virtual machine is on internal or external storage, and the guest OS inside the VM is completely unaware of the physical location of the VM. You can use VMware snapshots (if you want) no matter where your VM is stored. If you are using an external drive dedicated to VM storage, there is no need to partition it or create extra volumes on it. You should exclude that drive from Time Machine backups and use a different method to back it up - I've explained why below. VMware Snapshots vs Time Machine Snapshots VMware snapshots and Time Machine snapshots are two unrelated mechanisms which have some similarities in behaviour and the same name, but considerably different purposes and scope. VMware snapshots are managed by VMware Fusion (or other VMware products) as a way of saving the state of a virtual machine at points of your choice, allowing you to restore to an earlier state. For example, you could create a snapshot just before doing something major like an OS upgrade, so you could easily revert to the prior state. Under the hood, VMware snapshots only need to maintain differences between the current state and saved state (the largest part of which would be differences in the content of virtual storage between the snapshot and current state). In VMware Fusion they are implemented using files inside the folder which contains the VM settings and its virtual storage, and they don't depend on special file system features. Time Machine backing up from an APFS volume makes automatic use of APFS snapshots to instantaneously save the state of the entire volume before each backup. This snapshot is a feature of APFS (Apple File System), which is the native file system for the Mac in recent macOS versions. Once an APFS snapshot has been taken, the file system maintains a read-only reference to the state of the entire volume as it was at the point of the snapshot, Ongoing changes to the volume continue to be stored normally. As long as an APFS snapshot exists, everything which differs between that snapshot and the current state of the volume will continue to occupy storage, e.g. deleting a file won't actually free any disk space if there is still a snapshot which holds the previous existence of that file, and if part of a file changes, the snapshot still has the previous state of that file. Snapshots maintained by Time Machine are eventually deleted automatically (which will free space) but in some situations this can take a while, e.g. if you have multiple Time Machine backup drives and some of them aren't regularly connected (which is my situation). Don't use Time Machine to back up VMs Since the introduction of VMware Fusion, it has been strongly recommended that you NOT use Time Machine to back up VMware Fusion VMs, because Time Machine relies on modification times to work out what changed, can get confused about the multiple files inside the virtual machine and may back things up in an inconsistent state, resulting in a backup which may be impossible to restore. That is why I'm using a separate backup mechanism for my VMs: I periodically clone the volume containing my VMs using third party cloning software such as Carbon Copy Cloner, at a point while the VMs are not running. On my previous Macs (mostly before the introduction of APFS) I used Time Machine settings to exclude the folder with my VMs from the backup. Since the introduction of APFS, I prefer to store the VMs on a separate volume. My reasoning is that if the VMs are on the same APFS volume as your user account, and you are using Time Machine to back up everything else on the computer, APFS snapshots made by Time Machine will include all VMs in their current state, even if you exclude the VM folder from the backup (since APFS snapshots are for the entire volume). If the VMs change significantly before the oldest APFS snapshots are deleted, this can lead to a massive waste of disk space for something which is not even being backed up by Time Machine. Keeping my VMs on a separate volume which is excluded from Time Machine means that changes in my VMs don't waste space in the APFS snapshots maintained by Time Machine for everything else on the computer. It doesn't make any difference whether my VM volume is on internal or external storage. If I was needing to do backups of live VMs, there is a product called Vimalin written by one of the regular contributors to this forum which can safely back up running VMs. Since my use of VMs is sporadic rather than frequent, I haven't needed it yet.

Some questions come to mind: What operating systems are you wanting to run in VMs? Why do you think you need to involve a tool like BalenaEtcher which appears to be for imaging systems on to partitions on an external storage device? Are you intending to do something resembling Boot Camp plus VM, i.e. have the ability to boot the Mac directly into the guest OS, or run the same system as a VM while booted into macOS? If not, then partitioning is a complete waste of time, adds unnecessary complexity, and it may be impossible to set up a VM for some OSes as a guest if they are in a partition. The normal way of running VMs in VMware Fusion is for the VM and its virtual storage to be implemented in files on the Mac file system. The default for a new installation is for the VMs to be in a folder inside your home folder on internal storage, but you can save them anywhere you like on directly attached storage devices. For example, on my 2019 MacBook Pro I put my VMs on a separate APFS volume on my internal SSD, so I could easily exclude them from Time Machine backups (I use a separate backup mechanism for the VMs) and to ensure that VM changes didn't affect the size of snapshots on my main volume (mostly used by Time Machine). You can do exactly the same with external storage, ideally an SSD with a fast connection for good performance: set it up with a Mac-native file system, create a folder on it called Virtual Machines (for example), and when you create  your VM, tell VMware Fusion to save it in that folder.

Where were you trying to set the date? That trick might work for an old El Capitan installer if you were doing it on a real Mac, in Terminal while booted from a USB installer, but getting to that point in a VM install could be difficult. As a general note, if your "date" command worked, but your attempt to set the date said "command not found" then you probably typed the command wrong, e.g. omitted the required space between the word "date" and the date you were trying to set. Even if you got that right, trying to set the date that way in Terminal on a normally booted macOS isn't going to work because it requires root privileges and could have all sorts of nasty side effects on software which doesn't expect the date to be changed back several years. I also note that your date parameter "0711141516" would be trying to set the date/time to 2016-07-11 14:15:00, not something in in 2015 as you thought. (The insane field order of MONTH DAY HOUR MINUTE YEAR doesn't help but is there because of the US convention of month/day and consistency with historic UNIX implementations.) A better approach would be to download a new copy of the El Capitan installer from Apple, which won't have the expired certificate and therefore doesn't need the date set backwards. Apple's support page for downloading old macOS installers is here: https://support.apple.com/en-us/HT211683 There is a catch: to get the El Capitan installer application out of the downloaded disk image you must run the installer package on a Mac which is officially supported by El Capitan. If your Mac is too new (introduced in late 2016 or newer) and you don't have easy access to an older Mac, my suggested workaround is to create a macOS VM for a newer version which your Mac run, then from inside that VM, run the installer package to create the El Capitan installer application, copy the application back to the host, then use it to create your El Capitan VM. This trick works because the installer package doesn't check model compatibility if it detects it is running in a VM. If you need more details, I've explained this in other threads in this forum previously.

The problem is that you are running a version of VMware Fusion which is too old for your macOS version, so it is incompatible (and is producing an unhelpful error message as a result). There were fundamental changes in macOS Big Sur which mean that VMware Fusion 12 is the oldest version which will work. Note that Fusion 10.1.6 is old enough that it wasn't officially supported on the previous two versions of macOS either, but it may have worked (with limitations). Fusion 11 added official support for macOS Mojave, Fusion 11.5 for macOS Catalina. See https://kb.vmware.com/s/article/2088571 If you are using VMware Fusion in a personal capacity only, and don't need the extra features in Fusion Pro, it is possible to get a free personal licence for VMware Fusion 12 Player. (It can be difficult to find but there have been other posts about it recently in this forum which should point you in the right direction.) If you are using VMware Fusion in any kind of business capacity or you need the Pro version, then you'll need to pay for an upgrade from version 10 to version 12.   Checking one detail: you don't mention your Mac model, but the fact you have 32 GB of RAM on macOS Big Sur means that it must have an Intel processor. There may be compatibility issues preventing you using VMware Fusion 12 if you are running Big Sur on an older Mac which does not officially support that macOS version. Check the release notes for details: https://docs.vmware.com/en/VMware-Fusion/12.2.3/rn/vmware-fusion-1223-release-notes/index.html If you had an Apple Silicon processor then you cannot run Intel-based virtual machines at all. VMware Fusion 12 wouldn't work, but you could run the VMware Fusion for Apple Silicon Technical Preview with ARM-based virtual machines. There is a separate forum for that software: https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-Tech/ct-p/3022

Terminology is a bit tricky due to multiple meanings of "virtual" in this discussion. Cores allocated to the VM should be regarded as physical cores only, ignoring hyperthreading. VMware's limit of 16 is based on the hyperthreaded cores, but performance is likely to be terrible if you actually try to use all of them. The general consensus from people in the community who seem to know their stuff is you should limit cores allocated to a single VM to one less than the number of physical cores in the host, i.e. no more than 7 for a Mac such as ours which has 8 physical cores. This ensures there is one physical core left for the host (including a second hyperthreaded core if needed). Based on my observed pattern of behaviour in the CPU window, it looks like VMware/macOS was mapping each of the four cores allocated to my VM into the first hyperthreaded core in separate physical cores, and was not using the second hyperthreaded core. In effect, my VM was using four of the eight physical cores (first hyperthreaded core active, second idle), while the Mac got to use the other four physical cores (or eight hyperthreaded cores) as it saw fit. With your VM using 6 cores near 100%, I'd expect to see every second core out of 12 hyperthreaded cores being used mostly by the VM, the other 6 hyperthreaded cores in that group idle, and the remaining 4 hyperthreaded cores being used by macOS for whatever else it needs to do. If the machine was heavily loaded, macOS might start pushing things into the second hyperthreaded cores of physical cores being used by the VM, but I suspect it only does that as a last resort, because the overhead of having threads from different processes running in the two hyperthreaded cores of the same physical core is quite high due to needing to switch process context.

One point I note: your Activity Monitor view is incomplete. It is showing "My Processes". The virtual machines may be running in processes which are not owned by your user account, therefore you should choose "All Processes" in Activity Monitor (under the View menu). I happen to have the same Mac model but I can't do a direct comparison because I'm running VMware Fusion 12.1.2 under macOS Catalina (therefore with VMware's hypervisor) whereas you are running VMware Fusion 12.2.3 on macOS Monterey (therefore with Apple's hypervisor). I expect there are differences between the hypervisors in how VM processes are managed on the host, but here goes anyway. Under VMware's hypervisor, the VMs run inside a process called "vmware-vmx" which is owned by root (therefore doesn't show up in "My Processes"). My Windows 10 VM is set to use 4 cores. Apart from update latency, on my Mac, the Activity Monitor figure for %CPU is at least four times the figure shown by Task Manager in Windows 10, which is consistent with the Mac counting 100% as one core fully active vs WIndows counting 100% as all cores fully active.  I initially had some dummy commands running which hold the VM at about 55% CPU according to Task Manager, and in Activity Monitor I see vmware_vmx is sitting pretty steady around 368%, with the overview at the bottom showing System usage around 22% to 24%. Pushing the VM further, I've now got it to 98% CPU in Task Manager (Resource Monitor shows all four virtual cores nearly pegged), and Activity Monitor is showing vmware_vmx around 400%, overview shows System at 25% busy (or higher depending on what else the Mac is doing). Note that the System figure in the overview shown by Activity Monitor is counted based on hyperthreaded cores, therefore 16 cores in total, not the 8 physical cores. The CPU usage graph in Activity Monitor shows I'm using at least half of every second core most of the time, with some variability and shuffling around. I'm not sure what the "mksSandbox" process does, but on my system there is also a process of that name which is a child of VMware Fusion, and it has negligible CPU usage (usually under 1% even with the VM very busy).   In your case, System is showing 30%, which means 16 * 0.3 = equivalent of 4.8 hyperthreaded cores being fully active. That sounds a little low for six cores in the VM being fully active, but is about right if your six VM cores were on average 80% busy.

This sounds like a case where you want to use "nested virtualisation". There have been other threads here regarding this not working well on certain Mac models, in recent macOS versions with recent VMware Fusion versions, so I suggest searching the forum for that phrase. I don't know if this is still a problem and my Macs running VMware Fusion happens to be ones that aren't affected so I can't test it myself.

A possible explanation for this problem is if the VM has got out of sync with the state of one of your modifier keys, e.g. it thinks you are holding down the Option key (Alt in Windows) or Command key (Windows key in Windows). Try pressing each of those keys by themselves, then releasing them, then see if the other keys are behaving normally. I have run into this before in a VM and in other contexts such as remote controlling computers via software like TeamViewer. A similar issue is if you have multiple keyboards connected to your computer and something is pressing on one of the modifier keys on the keyboard you aren't using. A recent example: I was helping someone whose Mac was exhibiting random key activity, and it turned out to be the Bluetooth keyboard they forgot to turn off before putting it into their bag.

The message is correct: VMware Fusion 11.5.x will not work on macOS 11 Big Sur or later, because of significant changes in the operating system. If your Mac has an Intel processor, then on macOS Monterey you can run VMware Fusion 12 Player or VMware Fusion 12 Pro, depending on whether you need the extra features offered by Pro. If this is for personal (non-commercial) use, there is a free licence available for VMware Fusion 12 Player, otherwise you are looking at a paid upgrade from version 11 to 12. If your Mac has an Apple Silicon processor (M1 or later), then you can run the VMware Fusion for Apple Silicon Tech Preview, which is covered in another area of the VMware Community: https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-Tech/ct-p/3022 and is due to get an update this week. Note that Apple Silicon Macs cannot run ANY virtual machines from an Intel Mac - you can only virtualise operating systems for the same processor family as the host, therefore only ARM-based operating systems on an Apple Silicon Mac. At present, certain varieties of ARM-based Linux are the only officially supported guests; Windows 11 for ARM can be made to work (with help from the community) but without licensing or support from Microsoft, and no official support from VMware (e.g. no VMware Tools); macOS guests won't work. If you need to virtualise an Intel operating system (including Windows 10 or earlier, Intel variants of Linux, or older macOS versions), then you need an Intel Mac.

512 GB would be the amount of storage you have, not the amount of memory. The memory in an M1 Mac is either 8 GB or 16 GB. You can check that in "About This Mac". If your Mac has 8 GB of memory then you certainly won't be able to reserve 7 GB of it for a virtual machine, because the host needs to use a fair amount of memory itself. Allowing for the operating system, graphics and the VMware Fusion's application, and assuming you aren't running much else on the host at the same time, I'd recommend allowing at least 4 GB for the host, therefore you should not attempt to allocate more than 4 GB memory to a single virtual machine (or a total of 4 GB between multiple VMs running at the same time). If your Mac has 16 GB of memory then it is feasible to have a virtual machine with 7 GB of memory, which would still limit your ability to run memory-hungry applications on the host at the same time.

Just to check: are you running Fusion 12? Older Fusion versions won't work on macOS Monterey. The most likely problem: if you don't remember where you got the macOS 10.12 installer, that might mean you got it long enough ago that it no longer works. There was a security certificate expiry a couple of years ago which killed all previously downloaded macOS installers. Download a fresh copy of the macOS Sierra installer from Apple and try again. Unfortunately they don't make this easy: you need a Mac which able to boot Sierra in order to get the installer. Your 2018 MacBook Pro is too new (its oldest supported macOS is High Sierra 10.13.6). As a starting point, this is the page where Apple provides access to the installers for older macOS versions: https://support.apple.com/en-us/HT211683 For High Sierra (10.13) and later, the link on that page takes you to a hidden App Store page from where you can download the macOS installer. It won't let you download the installer if your Mac model is too new to run that macOS version. For Sierra (10.12) and earlier, the link downloads a Disk Image (.dmg) file. When you open that you will find it contains an installer package. Opening that package and running through the installer creates the "Install macOS version.app" application in the Applications folder. You won't be able to do this if your Mac is too new, because the installer package checks the Mac model is supported by the macOS version you are trying to install. If you don't have easy access to an older Mac, there is a workaround involving virtual machines. 1. Download the installer for a newer version of macOS which does support your Mac model. 2. Create a virtual machine using the newer macOS version. It will need a minimum of 20 GB of disk space (possibly more for recent macOS versions). 3. Boot into that VM and do minimal setup. 4. Install VMware Tools so you can easily copy files between the host and VM. 5. Inside the VM, download the disk image for macOS Sierra (or copy it from the host to the VM, if you already downloaded it). 6. Inside the VM, open the disk image and the installer package, proceed with installation. The model compatibility check is bypassed if it detects it is running inside a VM. 7. Copy the resulting "Install Mac OS Sierra.app" from the VM's Applications folder to the host. 8. Shut down the VM. If you don't need a VM running that newer macOS version, you can delete it to save disk space. 9. Use the "Install Mac OS Sierra.app" to create a VM for macOS 10.12.   A similar trick works to get the installer for High Sierra (10.13) and later, if your Mac model is too new to run that version: you can use the support page link and download the High Sierra or later installer inside a VM, because the compatibility check done by App Store is bypassed if it detects it is running in a VM.

When you say "When I got to the Apple Store and try to download the installer, it simply will not.", do you mean that when you go to App Store you cannot find the macOS 11 Big Sur installer? If so, that is normal: Big Sur is no longer the current version of macOS, and App Store only gives easy access to the current version (which is currently macOS 12 Monterey). To download the full installer for an older macOS version you need to use an indirect method. Apple has a support article which provides links for each available version. For macOS 10.13 High Sierra and later, the link takes you to a hidden page on App Store from which you can get the installer. It will end up in your Applications folder, named along the lines of "Install macOS name.app". For OS X 10.10 Yosemite through macOS 10.12 Sierra, the link gets you a disk image (.dmg) file in your Downloads folder, which contains an installer package. Running that installer package creates "Install macOS name.app" or "Install OS X name.app" in your Applications folder, after which you can eject the mounted disk image and delete the disk image file. In both categories, the installer is for the latest minor version of the OS (e.g. Big Sur downloaded now would be 11.6.4, which was released this week). Note: to get a particular macOS version, your Mac model must be supported by  that version. If you need an older or newer version, the workaround is to create a virtual machine for a macOS version which supports your Mac model, then download an older or newer version inside the virtual machine, and move the installer back to the host to use it for creating a virtual machine. Command line method If you are running macOS 10.15 Catalina or later, there is also a command line method to download the installer for recent macOS versions: softwareupdate --fetch-full-installer --full-installer-version 11.6.4 (specify the version number at the end). If you are running macOS 11 Big Sur or later there is also a way to find out which versions of the installer are available via the softwareupdate tool (it only lists available versions supported by your Mac): softwareupdate --list-full-installers Recently, Apple has made a wider range of minor macOS versions available via the command line method. For example, my 2019 16-inch MacBook Pro (which originally shipped with 10.15.1, can't run anything older, and is currently running 12.2.1) lists these versions: % softwareupdate --list-full-installers Finding available software Software Update found the following full installers: * Title: macOS Monterey, Version: 12.2.1, Size: 12155426708K, Build: 21D62 * Title: macOS Monterey, Version: 12.2, Size: 12156325205K, Build: 21D49 * Title: macOS Monterey, Version: 12.1, Size: 12157035487K, Build: 21C52 * Title: macOS Monterey, Version: 12.0.1, Size: 12128428704K, Build: 21A559 * Title: macOS Big Sur, Version: 11.6.4, Size: 12439328867K, Build: 20G417 * Title: macOS Big Sur, Version: 11.6.3, Size: 12435122667K, Build: 20G415 * Title: macOS Big Sur, Version: 11.6.2, Size: 12433351292K, Build: 20G314 * Title: macOS Big Sur, Version: 11.6.1, Size: 12428472512K, Build: 20G224 * Title: macOS Big Sur, Version: 11.5.2, Size: 12440916552K, Build: 20G95 * Title: macOS Catalina, Version: 10.15.7, Size: 8248985973K, Build: 19H15 * Title: macOS Catalina, Version: 10.15.7, Size: 8248854894K, Build: 19H2 * Title: macOS Catalina, Version: 10.15.6, Size: 8248781171K, Build: 19G2021 All minor versions of macOS Monterey are available, but only late minor versions of macOS Big Sur and macOS Catalina. I've found that the latest version sometimes doesn't appear in the list, e.g. 11.6.4 wasn't shown until I actually downloaded that installer, or tried to download a nonexistent future version. For comparison: a 2015 MacBook Air running macOS Big Sur also lists 10.14.6 and 10.13.6, because those versions can run on this Mac. (macOS 12 Sierra and earlier have never been available via this method.)

What is the database software in question? For example, I used FileMaker Pro back as far as version 3 and kept notes on OS compatibility: I see that versions 9 and 10 officially supported up to Mac OS X 10.5 Leopard but not 10.6 Snow Leopard (that was officially supported in version 11, which also raised the minimum to Mac OS X 10.5.7). FileMaker databases are easily converted to later versions: versions 7-11 had the same file format, with a conversion step required to go to version 12 or later.

It is possible to run Mac OS X Leopard Server (10.5) in VMware Fusion: I still have a working VM with that version, which I set up in about 2013. The key problem is finding a copy of Leopard Server, and at a reasonable price. Unlike Snow Leopard Server, which as @gringley noted Apple was selling for US$20 for many years, Leopard Server was never discounted and it was much harder to find after it was superseded by Snow Leopard Server. Its original price was US$499. If any aftermarket copies are still in the hundreds of dollars, an old Mac would be cheaper. I managed to get my copy of Leopard Server when a client decommissioned their PowerMac G5 which was acting a server - I paid them a moderate price for the server software and we sold the computer after reinstalling a non-server edition of Mac OS X. As with Snow Leopard Server, Leopard Server came with a card that had a printed licence key, which must be entered at installation time. If you do buy an aftermarket copy, make sure the licence key is included. If the software is PowerPC-only then there is the question of whether it is compatible with Rosetta and Intel Macs. If it does work in Rosetta, I'm curious why it would work in Tiger and Leopard but not Snow Leopard: off the top of my head, the only obvious omissions in Snow Leopard were that it dropped support for all PowerPC Mac models, and the removal of the last parts of the AppleTalk stack.

Based on a quick glance through the GNS3 web site and a web search, it appears that GNS3 is effectively an x86/x64 (Intel/AMD) operating system with the ability to run in a VM on multiple host platforms and VM software (including VMware Workstation, VMware Fusion and ESXi). As such, it would run in VMware Fusion on an Intel Mac, but cannot run in VMware Fusion on an M1 Mac, because virtualisation requires that the host and guest have the same processor family. M1 is based on the ARM architecture, not the Intel/AMD x86 architecture. Unless GNS3 do a port to allow it to run on ARM-based platforms, the only way it could run on an M1 Mac (or later Apple Silicon Mac models) would be via emulation software such as QEMU. I have no idea how well this would work, but I'm fairly confident it would be slower than running it on an Intel Mac in virtualisation, and it would not surprise me if it was missing some functionality and/or was less reliable.

Even if the gfxCardStatus was a good solution (it isn't: for many many macOS versions, its "force discrete graphics" feature has been unreliable), that will only help a small subset of Mac models which have both integrated and dedicated graphics, i.e. selected models of 15-inch MacBook Pro (which can't officially run macOS Monterey, i.e. 2014 or earlier). gfxCardStatus is not an option for iMacs, Mac Minis, 13-inch MacBook Pros, MacBook Airs or other models which only have integrated graphics. There were also some low-end Late 2013 and Mid 2014 15-inch MacBook Pros which only had an integrated GPU.

What you are trying to do is impossible. Virtual machines with an Intel-based guest operating system require the host computer to also have an Intel processor. The M1 is not an Intel processor (it is Apple Silicon, which is based on the ARM architecture). No current or future version of VMware Fusion will solve this: it is impossible to run a virtual machine on a different processor architecture. (Doing that would require an emulator for a different processor and platform. VMware Fusion is not an emulator. Competing products like VirtualBox and Parallels Desktop won't help as they are also virtual machines, not emulators.) If you need to be able to keep running your existing Intel VMs, you need an Intel Mac (if you don't have any macOS guests, you could also switch to VMware Workstation on a Windows PC). There is a separate area of VMware Community for the Fusion for Apple Silicon Tech Preview. This would let you run newly created guests with an ARM-based operating system on an M1 Mac. The preview supports some variants of ARM Linux. macOS guests don't work at all. The Insider Preview of Windows 11 for ARM guests are unsupported but the community has managed to get it working with limits: Microsoft does not offer a licence which permits the use of the ARM version of Windows on Apple Silicon processors, therefore VMware cannot support it, therefore there are no VMware Tools for ARM Windows. Older versions of Windows are out of the question.

Is your newer Mac running macOS Monterey a model with an Apple Silicon processor (M1 or M1 Pro/Max)? If so, there is no possible way of running VMware Fusion 12 (or earlier) on that Mac, nor is there any way you can use your existing virtual machines, all of which require an Intel processor. Apple Silicon Macs can run Fusion for Apple Silicon Tech Preview, which has its own discussion forum linked from that page. All virtual machine products which run on Apple Silicon can only run ARM-based operating systems as guests, because virtualisation requires the guest and host to have the same processor architecture. At present, the Fusion Tech Preview only officially supports a selection of ARM-based versions of Linux. The ARM version of Windows is not officially supported (Microsoft doesn't license it to end users and does not support it on Apple Silicon, so VMware doesn't support it either, in particular there are no VMware Tools) but the community has managed to work out ways of getting the Windows Insider version to run with limitations. macOS guests do not work at all.   If your newer Mac running macOS Monterey does have an Intel processor, then there is something else going wrong. Please provide more details about the Mac on which you are trying to get Fusion 12 to work, particularly the Mac model and processor details.

@daemonspudguy Based on the CPU information in your log, your Mac model is either "MacBook Pro (13-inch, Mid 2012)" or "MacBook Pro (Retina, 13-inch, Late 2012)". You can confirm this in About This Mac under the Apple menu. Those Macs do not have dual graphics so any workarounds which require that will not help you. As earlier posters have stated, macOS Monterey does not support MacBook Pro models introduced prior to 2015. The only way you could have Monterey running on a 2012 MacBook Pro is via a third-party hack, since standard Monterey will refuse to boot on that model (same for macOS Big Sur). Furthermore, VMware Fusion 12.2.0 and 12.2.1 have a minimum requirement of an Intel Mac model officially supported by macOS Big Sur 11 or later. For a MacBook Pro, that means it must be a Late 2013 model or newer. To run VMware Fusion in a supported configuration on your 2012 MacBook Pro, you need to be running VMware Fusion 12.1.2 or earlier, and preferably run it on macOS Catalina, since macOS Big Sur is also not supported on your model. Fusion 12.1.2 won't run on macOS Monterey. The problems you are experiencing with Fusion 12.2.1 on macOS Monterey are almost certainly caused by VMware Fusion 12.2.x requiring CPU or graphics features which don't exist on your Mac model. If you specifically need to be able to run Fusion 12.2.x then you will need a 2015 or newer Mac model with an Intel processor.

There is no possibility of ever running VMs created in Fusion 6 on an M1 MacBook Air. If the OS running in the guest is for an Intel processor (as will be the case for all VMs which run in any version of VMware Fusion on an Intel Mac), then the host must also have an Intel processor. With an M1 (ARM) processor, your new MacBook Air will be able to run ARM-based guests, which currently requires the Tech Preview of VMWare Fusion for Apple Silicon, the community for which is over here: https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-Tech/ct-p/3022 Note that the tech preview's only supported guest OS is ARM Linux (a few variants). ARM Windows 11 exists but Microsoft does not licence or support it for use on Apple Silicon Macs, so VMware doesn't provide any official support. There is also no support for macOS guests at this stage (if there is in future, it would be limited to versions of macOS which run on Apple Silicon, i.e. macOS Big Sur or later).