dempson's Posts

I don't know the answer to your question, but regarding Fusion versions and macOS Compatibility: Fusion 12.0 through 12.1.2 run on macOS 10.15.x Catalina, so upgrading to Fusion 12 would allow you stay on the same macOS version as long as you download the installer for an older minor version of Fusion. Fusion 12.2.x requires macOS 11 Big Sur or macOS 12 Monterey. Fusion 13 requires macOS 12 Monterey or macOS 13 Ventura. Fusion 12.0 thru 12.1.2 on Catalina is the last combination using VMware's hypervisor. Fusion 12.2 and later on Big Sur or later uses Apple's hypervisor, which changes several behavioural details and has some limitations in areas such as advanced networking and nested virtualisation (depending on the specific processor in your Mac). Fusion 13 has been released and Fusion 12 is no longer being sold, but you can upgrade from Fusion 11 to 13, and it should be possible to downgrade the Fusion 13 licence to Fusion 12. I haven't tried that. I also haven't heard confirmation yet whether a "free for personal use" Fusion 13 Player licence allows downgrade to Fusion 12 Player.

If the device/VM keeps coming back then it is still signed in to the Apple ID. Every time you start up the VM it will be logging back in again. You haven't given much information about your situation but I'll assume it is a macOS VM. Details vary somewhat depending on the version of macOS. I'll assume for this example that your VM Is running macOS 12 Monterey (some details about earlier macOS versions mentioned in passing). If you don't want that VM signing in to your Apple ID any more (including Find My), then you need to start up the VM and go into its System Preferences. If the VM is signed in to an Apple ID at the user account level then there will be an "Apple ID" icon in the top row. Click that to see details. If you want to sign out you need to go to Overview and at the bottom is a "Sign Out…" button. Signing out will require authentication in some cases, and may ask you about whether you want to keep some types of data on the Mac (VM) if they were being synced with iCloud. If the VM is not signed in to an Apple ID at the user account level then there is just a Sign In button in the top row. Nothing to do at this point. (In somewhat older macOS versions, the above was managed via the iCloud preference pane.) Whether or not the VM was signed in at the top level, there are other ways the VM might also be signed in to your Apple ID, and some of these will trigger it appearing in the list of devices signed in to your Apple ID (particularly the first one below). Check the following areas for a reference to your Apple ID: System Preferences > Internet Accounts. You can potentially sign in to multiple secondary iCloud accounts here (e.g. for shared contacts, calendars, etc., another iCloud-hosted email account, or to use one device to do two-factor authentication for multiple Apple IDs). The rest of these are in separate applications. App Store: shows the signed-in Apple ID name in the lower left corner. Click that for account details. You can sign out via the Store menu. Books: shows the signed-in Apple ID name in the lower left corner. Click that to see details. There is a Sign Out button in the account details window, or you can sign out from the Account menu. Music (iTunes in macOS 10.14 Mojave or earlier): shows the Apple ID you are signed into in the Store menu, from which you can sign out. TV: similar to Music. Podcasts: similar to Music. Messages: go into Preferences > iMessage and sign out if it is signed in to the Apple ID. FaceTime: go into Preferences > Settings and sign out if it is signed in to the Apple ID. No more occur to me at the moment.

There are are several ways to remove an unwanted device from your Apple ID. If you have access to the device (in this case a VM), sign out of your Apple ID everywhere it is referenced on that device (iCloud, App Store, iTunes/Music, iBooks, Messages, FaceTime). Some devices sign out from multiple services at once. If you don't have access to the device/VM: (a) If you have an iPhone or iPad signed in to that Apple ID: you can go into Settings > Apple ID (at the top), scroll down to the list of devices, tap the unwanted device, then tap the "Remove from account" button. (b) Sign in to https://appleid.apple.com from any device using your Apple ID and password. Click on Devices in the category list. Click on the unwanted device. Click the "Remove from account" button. There is also a mechanism to remove devices from an iCloud account via https://icloud.com then going into Account Settings, but checking mine it only lists some devices signed in to iCloud (might be missing ones I haven't used recently, which are the state of needing re-authentication to access iCloud, or which are running older OS versions), and doesn't list any devices signed in to my Apple ID for other reasons, but not signed in to iCloud.

@Technogeezer wrote: @dempson wrote: I'm pretty sure the above point is not correct - it certainly wasn't how the original Rosetta worked for PowerPC to x86. The developer documentation for the x86 to ARM version uses the same description, e.g. https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment You could be right, although I thought I had read somewhere about the frameworks running native. In some strange sense, having the framework code (which should be shared libraries, right?) in 1 architecture is pretty attractive. Maybe Apple learned something between Rosetta and Rosetta 2? The fundamental issue with the PowerPC to Intel transition was different calling conventions between the two processor architectures. The translation can't rewrite the logic of the code, just reimplements the instructions and remaps the registers. This means PowerPC-to-Intel translated functions had different rules from Intel native functions, rendering them unable to call each other. It wouldn't surprise me if the same issue arises with Intel to ARM, as again we are dealing with CISC vs RISC instruction sets, with one architecture having a lot more registers than the other. Intel-to-ARM translation may be easier than PowerPC-to-Intel and perform better because it is going from an architecture with "few" registers to one with "many" registers, allowing all the Intel registers to be held in ARM registers, whereas PowerPC-to-Intel translation would have needed some memory-based method to store all the PowerPC registers.

@Smith_67 wrote: Thanks for the explanation. I ordered a 2019 Intel based MacBook Pro yesterday as I figured this was going to be the answer. I now also have 2 MacBook Pro machines, one with M1 Max and one with Intel core i7. Not ideal, or a cheap solution, but it has solved my problem. That was effectively my solution as well, but only by accident - I bought a 2019 16-inch MacBook Pro when it was released (planning for it to be my long term replacement for the 2013 15-inch model), then Apple announced the Apple Silicon transition several months later. I got a 16-inch M1 Pro MacBook Pros after they were introduced, which will be my long term computer, with the Intel 16-inch model being relegated to secondary tasks including running x86 VMs.

@Technogeezer wrote: All of the macOS frameworks and system libraries (for example all of the graphical user interface) run natively in ARM code -regardless of if the application has been translated via Rosetta from an Intel binary or a native ARM binary.  I'm pretty sure the above point is not correct - it certainly wasn't how the original Rosetta worked for PowerPC to x86. The developer documentation for the x86 to ARM version uses the same description, e.g. https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment Note this bit: The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically. That means all system library/framework code which is called from an x86 process must also be x86, translated to ARM for execution (at least the system code only needs to be translated once per system update due to caching). Other parts of the OS which run outside the application process (e.g. the entire kernel and kernel level drivers) are ARM, as can be separate processes invoked from the translated code via methods such as XPC. Drawing code for the GUI is probably x86 translated code, but the rendering of windows to the display is done by WindowServer, which is a separate process and will be native ARM. As for the question of relying on Rosetta or on Intel Mac support, consider Apple's history in these transitions. The x86 code in the system is needed both for Rosetta on Apple Silicon Macs and for macOS booting on Intel Macs. Once we reach the point that that a future macOS version drops support for the last Intel Mac models, Apple could drop Rosetta 2 in the same version to save space and development/testing work for the x86 code. If the last Intel Macs are discontinued later this year, the Intel Mac cutoff point might be as little as three years away. Security updates let you stretch either cutoff point another two years. For the previous PowerPC to Intel transition: August 2006: last PowerMac G5 discontinued November 2006: last Xserve G5 discontinued (final PowerPC model) August 2009: Snow Leopard 10.6 introduced, dropped support for the last PowerPC Macs July 2011: Lion 10.7 introduced, dropped Rosetta September 2013: final security update for Snow Leopard (and systems including Rosetta) There was a gap of three years between the last mainstream PowerPC model being discontinued and a new macOS version not running on that model (less than three years for the Xserve). I'd regard that as a minimum, given AppleCare and hardware support timeframes. There was a gap of one version and almost two years between PowerPC hardware support and Rosetta being dropped, but we can't assume Apple will follow a similar pattern this time.

@Smith_67 wrote: I understand that right now it's not possible to run a usable Intel based VM on a Mac with a M1 cpu (much to my dismay) but I'd like to know if that is likely to change at some point in the future. Is it something that could happen if software was developed to allow it to happen, or is it just something that can never physically happen because of the differences in hardware? Virtualisation of x86 on ARM is not possible because by definition virtualisation requires the same processor architecture on the host and guest: most CPU instructions in the guest OS and applications are executed directly by the host processor. If the guest and host have different architectures (as with x86 vs ARM), the closest you can get is if the host implements a software emulation of the full instruction set of the guest CPU, interpreting each instruction as it is executed. This is a lot slower than virtualisation. It boils down to a question of how fast the software in the VM is expected to run. An Apple Silicon Mac can probably emulate an x86 PC running an OS from the early 2000s at a speed resembling the performance of a real PC of that era. If you want to run a modern OS and applications in the guest (say anything from the last decade) then its performance will be a lot slower than a real PC. Anything time critical will not work, and other software will be painfully slow. The emulation may also be incomplete, e.g. it may not cover some advanced features of the processor, or some other components in the computer, so applications which depend on those won't work. VMware have stated they are not intending to provide full x86 emulation for VMware Fusion on Apple Silicon Macs: it would require a lot of development effort and there is not likely to be a sufficient market of people willing to pay for such a feature. (Especially once you factor in the performance limitations.) Parallels and VirtualBox don't seem likely to do this either. There is at least one existing open source emulation product (UTM) but it appears to be missing functionality and is not stable enough for serious use. Running an ARM guest OS with x86-to-ARM code translation inside that seems a more viable solution for running arbitrary x86 applications, as this is a simpler problem to solve. Microsoft already provides an implementation of this for ARM Windows 11. That won't help for use cases such as running older versions of macOS and Windows. For those (my main reason for using VMware Fusion since version 1), I've kept an Intel Mac running VMware Fusion, but it is no longer my primary Mac.

This is a fairly well known problem which I first saw with guests running OS X 10.10 Yosemite, and in a later update of VMware Fusion it also affected guests running OS X 10.11 El Capitan. There is a compatibility problem between VMware Fusion's USB support and some older macOS versions. The solution: go into the settings for the virtual machine and change the USB settings to disable USB 3.0 and force the VM to use USB 2.0. Details are in this discussion thread (and probably several others): https://communities.vmware.com/t5/VMware-Fusion-Discussions/Keyboard-Mouse-not-working-in-Yosemite-Virtual-Machine/m-p/2293261#M139733  

Based on the repeated occurrences but seeming to only affect some people, I'd be inclined to suspect an updater for a third-party application which happens to be installed by the people in question but not by others. There have been known cases of this sort of thing in the past, where an installer or updater messed with permissions on standard folders.

And I can confirm that 12.1.2 installed and worked fine on one of my Intel Macs running macOS Catalina when I set it up a few months ago (well after 12.2.x was available). This was a fresh install on a Mac which had never had any version of Fusion installed. @fpassold  If you are having trouble with Fusion 12.1.2 crashing during install on Catalina then there may be something messed up on your system, for example something left over from an old installation of Fusion. I've seen mention on this forum of a process for completely uninstalling old versions of Fusion then trying the new version again. I haven't gone hunting for the details as I've never needed to do that myself.

@rafaelfalcon wrote: As part of the url article posted, it is that my MacBoo Air 2017 will not support MacOS Ventura, I hope that this article fails because of two year ago I have changed my 2012 MacBoo Air because it does no support new MacOs releases. Any way, the article is clear and so, thanks you for your help. Sorry to be the confirmer of bad news, but your 2017 MacBook Air will not be able to run macOS Ventura. It is excluded from Apple's official support list, which you can see near the bottom of https://www.apple.com/macos/macos-ventura-preview/. (You might be able to get Ventura working with a third-party hack but that is not a supported configuration for Apple or VMware Fusion; macOS Ventura running that way is likely to be missing support for some existing hardware features, have more compatibility issues than expected, and be less stable.) The 2017 MacBook Air is the only 2017 Mac excluded from Ventura, because it is technically identical to the 2015 MacBook Air, apart from minor hardware changes such as more storage in base models, and in one of the base models a slightly faster CPU (of the same generation). The key reason these models are excluded is the processor generation: all Intel Macs supported by macOS Ventura have a generation 7 (Kaby Lake) or later processor, whereas the 2015/2017 MacBook Air has a generation 5 (Broadwell) processor. This also means you may not be able to run macOS Ventura in a virtual machine on a 2017 MacBook Air, because parts of Ventura are known to require processor features which do not exist in older processor generations. macOS Monterey is expected to get a further two years of security updates so you don't need to panic, but you will need a plan in two years time if you want to keep running VMware Fusion in a supported macOS version on an Intel Mac (required for Intel guest operating systems). If you are looking for another Mac soon, I'd recommend avoiding other 2017 models as they might be dropped by macOS 14 next year. If you can delay the decision until mid June 2023 then we'll be able to confirm which models will be supported by macOS 14. For using VMware Fusion you'd also be better served with a Mac that has more than two CPU cores (only having two cores can result in performance problems with virtualisation if your guest OS needs two cores, including Windows 10/11 and macOS guests). You should also make sure the Mac has at least 16 GB of memory and plenty of storage for your VMs. Considering 2018 and later Intel Mac notebooks only, a minimum of four cores narrows the options to this list: 2020 MacBook Air with a Core i5 or Core i7 processor (not the entry level 1.1 GHz model with a Core i3). 2019 or 2020 13-inch MacBook Pro with two Thunderbolt 3 ports. 2018, 2019 or 2020 13-inch MacBook Pro with four Thunderbolt 3 ports. 2018 or 2019 15-inch MacBook Pro. 2019 16-inch MacBook Pro. If desktop Macs are an option, you can add the following to the list. I'm excluding most iMacs because they don't have a T2 security chip and I'm thinking Apple might require that for Intel Macs in a future macOS version, which would result in the 2017 and 2019 iMacs (including all 21.5-inch iMacs) being dropped earlier than other models. 2018 Mac Mini (still sold new by Apple but probably not for much longer). 2020 27-inch iMac with Retina 5K display. 2017 iMac Pro (the only 2017 model likely to be supported for longer than the rest from that year, and it has a T2 chip). 2019 Mac Pro. Looking further ahead, we all need to plan for the eventual end of macOS support for all Intel Macs, which also means VMware Fusion would stop supporting Intel Macs, and it would no longer be possible to run Intel-based guest operating systems in a VM on an Mac which is still getting security updates. There are several options beyond that point, which mainly depend on whether you still need to run Intel-based guest operating systems in a VM.

@JorgeH1 wrote: Sorry, I missed that question. I'm running ESXi on a MacPro 6.1 (trashcan) 6 CPUs x Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz. Hope this helps figuring out why not running on my ESXi (7.0U3). Thanks. That is the Late 2013 Mac Pro. As I said in my previous message, it will not be possible to run Ventura in a VM on that model because its processor is too old, and Ventura is known to require the use of features introduced in newer processors. It doesn't make any difference whether you are using ESXi, VMware Fusion or a competing virtualisation product. Virtualisation means the instructions are executed by the real processor, so if the guest OS in the VM needs a newer processor, there is no workaround. Your crashing boot loop is happening because Ventura is trying to execute missing instructions, which don't work on your Mac, so the kernel panics and reboots (every time). To run Ventura in a VM you will need a newer Intel Mac. For safety (as I noted) you should use a Mac model which has an Intel processor and is officially supported by Ventura, as listed in the article linked by @ColoradoMarmot, or in brief any 2017 or later Intel Mac model apart from the 2017 MacBook Air.

@JorgeH1 wrote: Thank you. I have tried those changes but still not working... Previous versions work with no problem. You didn't answer a key question from @gilby101: which processor does your host Mac have, or alternatively, exactly which model is it? Ventura raised the minimum Mac model requirement by about two years compared to Monterey. For Intel Macs the cutoff point is that all supported models (2017 or later excluding the 2017 MacBook Air) have a Kaby Lake (7th gen) or newer processor, all excluded models have a Skylake (6th gen) or older processor. For comparison, Monterey ran on selected models with Ivy Bridge (3rd gen) or newer processors, as did several preceding macOS versions. Because of the higher minimum processor implied by the list of supported Mac models, macOS Ventura expects it can use instructions and hardware features which were introduced in Haswell (4th gen), Broadwell (5th gen), Skylake (6th gen) or Kaby Lake (7th gen). This would apply whether booting natively or running macOS in a VM (Fusion hosted on an older macOS version, or ESXi). It is known that some parts of Ventura are using AVX2 instructions which were introduced in Haswell, therefore any Mac with an Ivy Bridge (3rd gen) or older processor is not going to be able to run Ventura in a VM. The most recent model this affects is the Late 2013 Mac Pro, which has an Ivy Bridge Xeon; it also affects all Early 2013 or older Macs. There may be parts of Ventura using other features introduced after Haswell: depending on exactly which feature is needed, this may cause problems or prevent running Ventura in a VM on Macs with a Haswell (4th gen), Broadwell (5th gen) or Skylake (6th gen) processor. That range includes Mid/Late 2013 Macs (apart from the Mac Pro mentioned above), all 2014-2016 Macs, and the 2017 MacBook Air. Any early successful results running a beta version of Ventura in a VM on an unsupported Mac should be considered provisional - Apple could make code changes in later beta or public releases which add more dependencies on newer processors, therefore your VM is at risk of breaking with every software update from Apple.

@cfpguy It would also be helpful to see the specifications of your laptop, since you want to run VMware Fusion on that. (I suggest you erase the serial number from your screen shot of About This Mac - we don't need to know that.) There are some technical details about the host Mac which are important to determine whether it is viable to run VMs at all. The main ones are CPU cores and memory: I'd recommend a minimum of four CPU cores and 16 GB memory, but you might need more of both depending on what specifications you need for the VM, and software you need to run on the host at the same time as the VM is running. All 15-inch and 16-inch MacBook Pros supported by macOS Monterey would qualify, but 2017 and earlier 13-inch MacBook Pros and almost all Intel MacBook Airs only have two CPU cores. Knowing the specific CPU will also allow us to answer the question of whether your Windows 10 VM would perform badly if you happen to need nested virtualisation. As with the iMac, you also need to allow at least 40 GB of disk space for each VM.

@cfpguyThe CPU and other specs of your iMac are fine for running VMware Fusion 12 and macOS Sierra as a guest. Disk space might be an issue: the VM will occupy at least 40 GB of disk space (more if you need a fair amount of disk space inside the VM). I normally run a macOS Sierra VM in VMware Fusion 11 on an older MacBook Pro but I also have a copy of that VM in VMware Fusion 12 on my Late 2019 16-inch MacBook Pro running macOS Catalina, which is a similar setup to what you want (details of the host Mac model are not important in this case.) The main issue I previously mentioned which is a potential problem for your use of macOS Sierra in a VM on the iMacs (under macOS Catalina) is the lack of 3D graphics support for macOS VMs. Which 32-bit applications do you want to run in macOS Sierra? Another complication I hadn't mentioned yet is the process to set up a macOS Sierra, which you might have run into when trying to set it up in Parallels. A few years ago, Apple changed the distribution method for downloading older macOS installers, specifically for macOS Sierra and earlier. It used to be a link to a hidden page on App Store (the same method still used for macOS High Sierra and later) but is now a downloaded disk image. That disk image cannot be used to create a VM directly: you first need to use the disk image to create a copy of the installer application for macOS Sierra. This can be done easily if your Mac is old enough enough to boot macOS Sierra (Mid 2017 or older), but if your Mac is too new (Late 2017 or newer) then there is a more complex process involving temporary use of a newer macOS in a VM. In your case, your Late 2014 iMac is old enough so the process is easily done on that computer, and you can do the preliminary steps before you have VMWare Fusion. 1. Download the disk image from Apple which contains the macOS Sierra installer. Apple has a page listing all the old versions: https://support.apple.com/HT211683 Use the macOS Sierra link near the bottom of that page to download InstallOS.dmg for macOS Sierra. 2. Open the resulting InstallOS.dmg file. It opens a Finder window showing the contents of the disk image. 3. Open the "InstallOS.pkg" installer package inside the disk image. This runs Installer. 4. Follow through the usual prompts, agree to the licence etc. and proceed with installation. The end result is that it creates a copy of "Install macOS Sierra.app" in your Applications folder. Keep that file and don't run it: you will need it to create a macOS Sierra virtual machine with VMware Fusion. You can copy the Install macOS Sierra application to your other Macs rather than having to go through the disk image method again. (If you try to do the above on a Mac which is too new to boot macOS Sierra, then step 4 will fail because the installer package refuses to create the Install macOS Sierra application unless your Mac is a model able to boot that version of macOS.)

@cfpguy wrote: Sorry, I was not clearer earlier. I have several Intel macs in my business. My laptop has Monterey and a couple of iMacs have Catalina. I want to use Fusion to run Sierra on all machines, What version of Fusion do I need? Down the road, I want to put Windows 10 on the laptop too. Will that impact what version of Fusion I need? Fusion 12 Player or Pro (specifically version 12.2 or later) will run on macOS Monterey on your Intel Mac laptop, and will let you run both macOS Sierra and Windows 10 guests. The same major version Fusion 12 also runs on macOS Catalina, but you will need to download and install Fusion 12.1.2 rather than the latest minor version (12.2 and later requires macOS Big Sur or later, 12.0.x and 12.1.x run on Catalina.) 12.1.2 will also support macOS Sierra and Windows 10 guests. Therefore three licences for Fusion 12 Player 12 or Pro should cover your current and near future requirements. Some technical issues might be a stumbling block: 1. Fusion on macOS Catalina or earlier uses VMware's own hypervisor. On macOS Big Sur or later, Apple's hypervisor is used. This affects some areas like advanced networking features (generally better on VMware's hypervisor). 2. Nested Virtualisation on Apple's hypervisor has major performance problems unless you happen to have one a limited set of Macs that have just the right CPU (we need to know exactly which Mac model you have, including its CPU configuration, to be able to identify this detail). Nested virtualisation may be an issue for Windows 10 depending on whether the software you want to run in Windows requires creating virtual machines, or you are using features like the Windows Subsystem for Linux. 3. For running macOS Sierra as a guest, there is one problem you need to know about (which apply to all hypervisors and all competing virtualisation products): no 3D graphics support. If you want to run applications on macOS Sierra which require 3D graphics, they will not work properly in a macOS VM. Some of these are not obvious ahead of time, e.g. Apple's iWork '09 suite (Pages 4.x, Numbers 2.x, Keynote 5.x) and earlier use QuickDraw 3D to render documents, which doesn't work unless you have a 3D graphics controller. This means you see blank documents if you try to run those applications in a macOS VM. (I've kept a 2012 Mac Mini running macOS Sierra partly so I can run those applications on rare occasions.) For planning ahead, if your laptop is new enough to run macOS Ventura: We don't know yet whether Fusion 12 will get a free update to officially support macOS Ventura or whether that will be a paid upgrade, but it is likely that it will be paid as we've had almost two years since version 12 was released. In the past, I've managed this by timing a licence purchase for Fusion after the point the new major version is announced, so I get the current version and a free upgrade to the next version due to recent purchase. VMware is having their conference in August and then or slightly later is probably when they will announce the next version of Fusion. We don't yet know if perpetual licences will continue to be an option, or whether they will switch to a subscription model (Broadcom is buying VMware and they have stated they prefer subscriptions).

@SteveBall wrote: Host is 2.4ghz 8-core i9 + 8GB Graphics card, so it shouldn't be dropping down the cores.  As noted by @bluefirestorm that processor doesn't have vPro or support VMCS shadowing therefore nested virtualisation will perform badly. I happened to buy the "right" model of the 16-inch MacBook Pro, with the 2.3 GHz 8-core i9 (Core i9-9880H) which does support VCMS shadowing, but I haven't needed that feature in anger yet because I'm still running VMware Fusion 12.1.x on Catalina when I need to use VMs. I don't want to have to deal with the various other annoyances people keep reporting here, which seem to be due to limitations in Apple's hypervisor. Here's hoping they improve it in macOS 13. I have the luxury of that Mac no longer being my main computer, so it isn't a hassle to leave it running an older macOS version, but the end of security updates later this year will increase the risk of continuing to avoid the Apple hypervisor. As for your later question about other virtualisation platforms: at the moment it seems that Parallels lets you use either the Apple hypervisor or their own one on Big Sur and Monterey. Third party kernel extensions are already deprecated, and they will be eliminated in a future macOS version, but Apple hasn't yet told us which version. When that happens, Parallels would also be forced to use Apple's hypervisor.

@Technogeezer wrote: While I agree that at some point in time Apple will stop supporting Intel Macs, I don't think that's particularly likely in the near term. After all they still are selling Intel Macs (the Mac Pro), and they just stopped shipping Intel iMacs. My tea leaves say that you'll see about another 2-3 years of new macOS releases supporting Intel models, with another 2 years of support after that, but that's just speculation based on what I've seen in the past. The PowerPC to Intel transition saw new macOS versions dropping support for some models as little as three years after they were discontinued (Snow Leopard vs the 2005 PowerMac G5). We're two versions into macOS with Apple Silicon support and no evidence yet of a cutoff as short as 3 years. If Apple sticks to their pattern over the last few years, then most Macs should be able to run the latest macOS version for at least 5 years after the model was discontinued, with some getting 6 to 7 years, and a minimum of 4 years in rare cases. The only recent example which got less than 5 years was the Mid 2012 non-retina 13-inch MacBook Pro which Apple kept selling until late 2016 (well after its contemporaries) and was dropped by Big Sur in late 2020. (Add two more years for security updates.) If the recent pattern continues, then the 2019 Mac Pro needs to be supported by at least the next four and probably five macOS versions, depending on when it is discontinued. It would be rather odd maintaining support for just one low volume Intel model, so it seems more likely they would eventually settle on a multi-model minimum such as "Intel models must have a T2 chip" (late 2017 iMac Pro, all 2018-2020 models except 2019 iMacs) until all Intel support is dropped. Next data point (models supported by macOS 13) is less than a month away.

No. The free personal use licence was introduced with Fusion 12 Player and those licence keys are not valid for earlier versions of Fusion, nor can they be downgraded. To get Fusion 11 now, you need to buy Fusion 12 Pro then downgrade the licence to Fusion 11 Pro via VMware Customer Connect. It appears that a paid licence for Fusion 12 Player cannot be downgraded to version 11, probably because there was no "Fusion Player" product prior to version 12. Can anyone else confirm this?