Technogeezer's Accepted Solutions

That’s the original 20.04 release. Try downloading the 20.04.4 from this link https://cdimage.ubuntu.com/ubuntu/releases/20.04/release/ubuntu-20.04.4-live-server-arm64.iso and retry the installation steps. 

I believe that external GPUs are now officially supported, given the indications in the Fusion 12.0 release notes. I'm not sure what the performance will be. My gut feeling is that it will be better than the integrated graphics in your MacBook Pro, but not sure what the overall performance will be. My reasoning: The VM's operating system will not have direct access to the eGPU features - just as the guest does not have direct access to an on-board GPU's features. The guest will be using a VMware SVGA graphics card driver, not a vendor graphics driver. That VMware driver interfaces with the virtual graphics adapter provided by Fusion, which in turn (IIRC) is implemented using macOS Metal API calls that get executed by the GPU. The Metal API should run faster, but the end result is dependent on VMware's implementation. A comment:  running a 4 core VM on a 4 core machine may starve the system for resources. It's recommended to use no more than n-1 cores of a host that has n cores (hyper threaded cores don't count)  to give the operating system some resources to support Fusion and anything else that might run on it. You may also want to verify how well each of those packages run under Fusion and its available 3D support without the eGPU. Speed is one thing, functionality is another (making sure everything works as expected).

Re: #1: Make sure your VM's virtual network adapter is configured to use bridged networking, not "Share with my Mac" a.k.a. NAT networking. Bridged networking will put the VM on the same network as your Mac's primary NIC and should allow the Windows VM to show up as a computer on the network. 

From a little bit of research and some web searching... There's one line in your strace that's interesting to me: write(0x9, "2022-04-13T16:28:21.055Z Wa(03) VMware Fusion RegisterHelperWithAuth: com.vmware.fusion.InstallHelper registered failed due to The operation couldn\342\200\231t be completed. (CFErrorDomainLaunchd error 9.).\n\0", 0xC7) = 199 0 That CFErrorDomainLaunchd error 9 is seeming to indicate that something in launchctl is disabling the launch of the Fusion install helper application. I just tried re-installing the latest TP on macOS 12.3.1 on my 2020 M1 mini and it's not giving me that error. So something's definitely weird on your system that is preventing the installer from completing properly. Just for ha-ha's could you run in a shell: id to get your current UID, then run launchctl print-disabled user/uid where uid is the user UID you got from the id command

I just downloaded and tried it. Same as you. The issue is that kernel isn't detecting the VMware CD-ROM device or the VMware SATA controller. Nor that ISO boot from the CD if you change its bus type to SCSI. That installer is using a 4.x kernel. That's an old kernel.  I'd stop beating your head against the wall and use the 20.04, which is known to work. 

Which Windows 11 edition are you trying to install? Did you enable Secure Boot as well as TPM?  Did you create your VM with at least 2 cores, 4GB of memory and 64GB of virtual disk? Windows won’t install unless these minimums are met. 

It could be possible that you have remnants of another Fusion installation (especially if you tried to use Fusion 12 or you migrated from another Intel Mac to an M1 Mac). Try the complete uninstall procedure in https://kb.vmware.com/s/article/1017838 then reinstall the Tech Preview. The installation will ask for a license key, but it will be pre-populated with a key that enables Fusion Pro functionality for the Tech Preview.  

When you booted that Boot Camp VM in Fusion, are VMware Tools installed? And is Fusion offering to upgrade them? Upgrading them or re-installing them might be a good first step. The Radeon software will not work when running that Boot Camp VM under Fusion. That's because the graphics adapter that any VM (including Boot Camp VMs) sees when running under Fusion sees is a VMware SVGA virtual graphics adapter. The VM can not control or access features of the hardware graphics adapter directly. Don't run the Radeon software when booted under Fusion as it won't do anything (except give you those error messages)...    

I doubt this is a VMware issue as I can’t think of any other OS that would report anything other than 8GB if you assigned it to the VM. I did some quick research that indicates that Sophos’s licensing controls the number of CPUs and memory that their XG Firewall OS can use. They may be constraining their memory use of the VM  based on your license.  I would double check your licensing, and if you can’t get an answer from that then contact Sophos. 

Along the same lines as @RDPetruska - how much memory have you allocated to your Win7 VM? That influences the size of a hibernate file, swap file size, and the need to use swap file resources (e.g your VM memory is too small for what you are doing so the VM starts swapping). 

None of what you did addresses the reported issue of improper permissions that macOS put on that folder. Nothing in the Fusion application install touches that folder - other than trying to load the kernel extensions, which improper permissions seems to prevent. . I'd give booting to Recovery, opening a Terminal and issuing that command at this point.

@licensedtoquill wrote: But he does suggest running FirstAid from recovery (meaning Internet startup,  command-R?) and later it is suggested that reinstalling (from that internet startup?) might cure the problem? Isn't there an easy way of throwing away the kernel extension staging folder & contents? I agree that the thread can be hard to follow. Here’s what I get out of it.  The commands $ xattr -l /private/var/db/KernelExtensionManagement com.apple.rootless: KernelExtensionManagement And ls -lO /private/var/db/KernelExtensionManagement/ are used to determine if the macOS folder required in the kernel extension loading process has the correct permissions. If not, the most successful advice to fix this is to boot to macOS Recovery. You should be able to boot to the on-disk macOS Recovery (Command-R) and not have to go to Internet Recovery (Option-Command-R or Shift-Option-Command-R).  Once in macOS Recovery, use the menu to open a Terminal, and issue the command  chflags restricted /Volumes/Macintosh\ HD/private/var/db/KernelExtensionManagement Then reboot. From the discussion in that thread and the posts it references, it appears that a macOS update has removed this flag from the specified folder, breaking the kernel extension loading process that Fusion and other third party products use. Reinstallation might fix the problem, but that’s a drastic solution and might not guarantee that the problem will be fixed. Someone else in the thread tried First Aid and it did not solve the issue.  And no there is not a way to simply throw away the folder, especially from the running macOS. It’s not a problem of contents. It’s a problem of correct permissions.  There is no guarantee that it would be recreated or that it would be  recreated with the correct permissions.  

From what I and others have found, RHEL 8.x for arm64 and other derivatives of those versions such as CentOS 8, CentOS 8 Stream,  or Rocky Linux 8.x will not install on the tech preview. I’ve been told those kernels are built using a 64k page size which won’t work. Red Hat has changed their arm64 kernels for a 4kb page size in RHEL 9 and this is the case for CentOS 9 Stream as well. If you want RHEL family releases that work on the tech preview, use Fedora 33, 34 or 35 RHEL 9 beta update 2 or later  CentOS 9 Stream (not 8 ) Take a look at my “Tips/Techniques/Gotchas” document https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-Tech/Tips-Techniques-Gotchas-for-the-Tech-Preview/ta-p/2893986 over in the Tech Preview Documents area that has a lot of advice on getting various distros working. It’s a one stop shopping destination compiled from what others have found in the various threads in this board. 

I looked at both the source link you posted and some systemd-boot info over at Arch Linux. Looks like the boot loader is trying to change display modes of the graphics adapter, and for some reason is choosing mode 1. That looks like something the VMware adapter doesn't understand.  There does appear to be a loader.conf(5) setting that might get rid of the message: console-mode This option configures the resolution of the console. Takes a number or one of the special values listed below. The following values may be used: 0 - Standard UEFI 80x25 mode 1 - 80x50 mode, not supported by all devices 2 - the first non-standard mode provided by the device firmware, if any auto - Pick a suitable mode automatically using heuristics max - Pick the highest-numbered available mode keep - Keep the mode selected by firmware (the default) I wonder a) if this value is set, and b) if a value of '0' for this parameter in the loader.conf might fix that error message.

I've installed a basic environment using instructions from https://nixos.wiki/wiki/NixOS_on_ARM/UEFI and I don't see this from either the installer or an on-disk installation. In fact my boot screens look totally different. What boot loader did you select for installation. The instructions say to use GRUB.  

I’m not a macOS kernel guru, but the module referred to in the message is in VMware’s folder sharing driver (vmhgfs). Turning shared folders off does seem to be an appropriate isolation step.  if you can, you might want to open an official VMware support ticket for this issue. You might get the attention of a VMware developer here, but having a support ticket opened makes it more likely at it will get into the proper hands to look at. 

I just fired up a Ubuntu 16.04 LTS VM on my Intel Mac Mini. I'm not seeing what you're seeing so something not obvious is going on. The lsof output isn't surprising since dnsmasq is serving as a local DNS proxy/forwarder. Do DNS queries through nslookup and dig appear to be coming back slowly on your VM as well as your Mac? If you ping by IP address rather than a hostname, does the ping still take seconds? What DNS server is being used by your VM? Search the system log (/var/log/syslog) for entries such as Feb 1 15:14:37 ubuntu16 dnsmasq[977]: setting upstream servers from DBus Feb 1 15:14:37 ubuntu16 dnsmasq[977]: using nameserver 172.16.73.2#53(via ens33) In my VM, I have NAT networking set and have the IP and DNS addresses being fulfilled by DHCP, and Ubuntu's networking is forwarding the DHCP-supplied DNS server address to dnsmasq.  

The insert of one row of a table at a time may not be able to be multi-threaded in and of itself. One strategy that might work is to try dividing the files you are loading into two sets. Run 2 copies of your script simultaneously, one for each set of files. Monitor CPU usage and elapsed time to see if this makes any difference. 

This doesn't sound like a Fusion issue to me. Fusion doesn't revert changes made to a virtual disk unless you have a snapshot active and then manually revert the snapshot. This is something that a guest VM operating system doesn't do. I'm running a Kali virtual machine and any changes I make persist to the image. This almost sounds like you're running a "live boot" version of Kali booted from CD/DVD and not from the hard drive. Typically changes made in a "live boot" environment will not persist across reboots.