Technogeezer's Accepted Solutions

Is there a log file ~.Library/Logs/VMware\ Fusion folder called vmware-vmfusion.log? If so, could you zip it up and post it to a reply? What macOS version are you running? Did the installer place the application file in your /Applications folder? I assume also that your installer .dmg was downloaded directly from VMware? Also, it's not a good idea to download OS installation media from sources other than the publisher. The procedures in the Companion Guide document get you an ISO whose contents are sourced directly from Microsoft.  

Let's start fresh. Use the procedure in the KB article https://kb.vmware.com/s/article/1017838 to fully uninstall Fusion and all of the other files it populates on the Mac. Simply moving the application to the trash is not sufficient. You must make sure you find and delete the files noted in the tech note in both /Library and ~/Library (the Library folder found in your account's directory) (the ~/Library folder is normally hidden, at the Finder menu hold down the Option key and then select Go > Library) . Open the .dmg file you downloaded from Vmware and then double click on the installer once again. And then be very specific on where any error messages occur. 

I’ve found that browsing the network from a Windows system won’t discover a Mac enabled for Windows file sharing. If you connect using the IP address or host name from Windows will work (e,g, typing \\machostname in Windows explorer) 

Are you running Fusion 13 Player or Pro? Here's a brief summary of the two relevant default network types for Fusion Player: "Share with my Mac" setting is a independent virtual NAT network. Hosts assigned to this virtual network are on an isolated network segment (although the host has an IP address on this network so the host can be directly accessed). They have access to the outside world through the NAT gateway that Fusion provides for the network. DHCP services are provided by Fusion to VMs that are connected to this network. "Private to my Mac" is another independent virtual network like the "Share with my Mac", but has no NAT connectivity to the outside world or to the host.  Fusion 13 Pro allows you to configure additional custom networks in its preferences: The custom networks have their own virtual network segments with their own IP address ranges and subnet mask, and can be more specifically configured to: allow/disallow the host to access the network segment define a NAT gateway to the host's visible networks provide/not provide DHCP services to hosts on the custom network.  

If you already have Fusion 13 Player installed (either using a purchased Fusion 13 Player key or a "free" personal use license key) there's no need to uninstall Fusion 13 to switch from Player to Pro. Start Fusion 13 and click  "VMware Fusion" on the Mac menu bar, then select "License...". Enter the new Fusion Pro key in the dialog, then exit and restart Fusion. You can verify through "About VMware Fusion" if the license key "took".

@lse123 wrote: My Intel Mac Book Pro 15-in LATE-2016, Not supports Ventura >>> Tried run Ventura 13.2 in free VMware Fusion but having very often Ventura OS auto Restarts and symptoms, this maybe because my hardware not supports Ventura??? Very likely.  You are running an unsupported configuration in the eyes of both Apple and VMware. All bets are off on how well Fusion runs on it or that it works at all. 

Assuming you are on an Intel Mac, Fusion is broken for its documented mechanisms for installing macOS. Neither using the recovery partition or drag/drop the Install macOS Ventura.app file on the  Create a new virtual machine dialog work. Apple changed the layout of the files in both of these in Monterey and VMware hasn’t caught up to the changes.  An installable ISO file of macOS  can be created by: Downloading the full installer (Install macOS Ventura.app) from the App Store using the info from https://support.apple.com/en-us/HT211683, or use the command   softwareupdate --fetch-full-installer --full-installer-version 13.3 Use the script from https://github.com/rtrouton/create_macos_vm_install_dmg to build an ISO from the Apple installer. (Choose the option that builds both a .dmg and .iso file) build a custom macOS VM and point the virtual CD/CVD drive to use the your newly created ISO

Some results on experiments that I just completed. Fusion 12.1.2 on Big Sur: No VMware dhcpd processes fired off by Fusion on macOS. The custom network dialog does not show an option to enable/disable use of DHCP for any custom networks. Fusion 12.2.6 on Monterey: VMware dhcpd processes are seen on macOS. The option to enable DHCP for custom networks appears for creation of Fusion custom networks. So unless someone can come up with a way at the macOS level to disable DHCP for one of the VMware networking segments on Big Sur, I'd say that it's not going to be easy to disable DHCP the way you want. If you can, I'd recommend upgrading to Monterey and Fusion 12.2.6.  Side note: perhaps this is one of the reasons why Fusion dropped support for Big Sur in Fusion 12.2?? Apple matured their APIs to allow VMware to take control of DHCP on the Fusion-created subnets?

Yes it is, IMO. The process copies 4 files into /Library/LaunchDaemons on Fusion start up. It removes them on Fusion shutdown. Because of Ventura's new security posture (and the deprecation of putting background processes in the system's folders), the warning message comes from macOS every time the files are copied into the directory. I've been reading up more on the Ventura changed behaviors. What you're seeing is not a bug, but is due to Fusion still using a now-deprecated method to configure background services. The messages from Ventura about background services will continue until VMware switches over to the new method of defining background services introduced in Ventura. (VMware might be able to reduce the number of times the message is repeated by copying the .plist files only once and leaving them there, but that doesn't fix the issue in its entirety). The new method keeps the keeps the .plist files and background serices code within the applications bundle. That allows them to be vetted by macOS  by the application's signatures and more gracefully "introduced" to launchd without having to move files to LaunchAgents or LaunchDaemon directories. Allowing almost anyone to put a plist file in /Library/LaunchDaemons or /Library/LaunchAgents and started via launchd is an invitation to unwanted behavior. 

A couple of thoughts.... Enable VNC connectivity to a VM's console through VMware Workstation. That way VNC client software on the Mac can be used to access the remote VM.s. However, VNC may not perform well and might be insecure. Enable Remote Desktop connectivity within Windows XP Professional running on the VM. You may be able to use the Microsoft Remote Desktop app (free install from the Mac App Store) to connect to the VM. This'll work best if the VM is configured with Bridged networking. (I'm not sure if the Remote Desktop app on the Mac considers Windows XP to be too old and insecure to talk to, but it's worth a try). Either one of these solutions may require that firewall settings be tweaked on the Windows 10 or 11 host operating system. Another thought is to ditch the laptop idea, get a small Intel NUC with sufficient memory and SSD, and run VMware's free version of ESXi on it. Then use the VMware Remote Console app (also available in the Mac App Store) to connect to the ESXi server and VM.  

The import process should create a copy of the Parallels VM's disk files (you can check that by locating the VM's bundle file (the ..vmwarevm file) in the Finder, right clicking on it and choosing "Show Package Contents" - that will open a Finder window that will show you all of the components of the VM). Once you verify that there are copies made of the virtual disk files, then go ahead and delete and remove both Parallels and the VM. You might want to save away a copy of the Parallels VM. Just in case.

You can try the following (make sure that you have a backup of the original virtual machine before you try any of this). This assumes that your virtual machine's guest operating system is supported by Fusion 11.5.5. Create a new custom virtual machine with Fusion 11.5.5 on Mojave After specifying the virtual machine type, you;; be asked for the virtual disks. Opt to use an existing virtual disk, and navigate to the VMDK file of your original virtual machine located in its "bundle" folder. Choose the file with the .vmdk extension that does not contain anything extra such as -s001.vmdk .Select it and opt to make a copy of the virtual disk. At the final dialog, choose to customize the configuration. Make any changes needed to make the new VM match the original.  See if the VM will power on.    

The functionality to mount an ISO file as a file system is built into Windows and has no dependency on Fusion. I've noticed that your screen shot at the beginning of this thread is saying the file type of your ISO file is "Windows.isoFile" file. It should say "Disk Image". Open the properties of that file, and make sure that the file is named "filename.iso" (has the .iso extension), not "filename.iso.some-other-extension".     

  @brazostrailers wrote: I'm running and insider build for ARM devices since I'm hosting off a mac, I might be wrong but I don't thinks it's possible to use a retail build when on a M1/M2 mac, is this not the case? That's 100% false. There's no need to use an Insider Preview build. Any references you see to it on Internet videos and blogs are seriously out of date, and you are setting yourself up for problems if you use them on Fusion because they have issues being updated when the builds expire. Did you install VMware Tools network and video drivers per instructions in the documentation? Networking won't work for Windows 11 VMs if you don't, and old advice you'll find on the Internet to enable the Windows debug adapter no longer work with Fusion 13. See the Unofficial Fusion 13 for Apple Silicon Companion Guide (https://communities.vmware.com/t5/VMware-Fusion-Documents/The-Unofficial-Fusion-13-for-Apple-Silicon-Companion-Guide/ta-p/2939907) for procedures on obtaining and installing the Windows 11 ARM 22H2 Retail release.  

Ventura removed support for many devices, and you may be encountering one of them.  First, make sure your guest OS type is set to "macOS 13"  Then, with the VM shut down and the settings panel for the VM dismissed, check the .vmx file and see if the ethernet0.virtualDev setting is e1000e. The cause of what you're seeing may very well be that that Apple removed the e1000e NIC driver from Ventura. A new macOS 13 VM will set the virtual NIC type to vmxnet3. but an upgrade or change to the guest OS type may not. To fix this, edit the .vmx file and change the value of that setting to read: ethernet0.virtualDev = "vmxnet3"  

I'm assuming you are running Windows 11 ARM on Fusion 13 on an Apple Silicon (M1/M2) Mac. Since there is no host/guest folder sharing capabilities for Windows 11 ARM like there is on Intel Macs with Fusion, section 12.8 of the Companion Guide discusses ways to work around the issue.  Have you tried any of those work-arounds?

The cabextract utility used in the process to create the ISO was recently updated in Homebrew, and contains a bug which causes this. To work around this, see Appendix D of the Unofficial Fusion 13 for Apple Silicon Companion Guide version 9.1 (it was just updated) that @scott28tt linked you to. Use that procedure to build and install an older version of cabextract that works. The developer is aware of this bug, and looks to have checked in a fix for it in the development version.  It looks like when that version is released this will no longer be an issue.

It's in the VMware Fusion Documents section of the forum Or search he forum (click the magnifying glass on top of the forum page) for "Companion" or "Unofficial". Or, here's the direct link:  Unofficial Fusion 13 for Apple Silicon Companion Guide.   

The work-around is to boot the VM  into the kernel that existed before the last update and do not update the VM further until Ubuntu fixes what they broke.  Consult the Ubuntu documentation on how to boot into an older kernel.