VMware Fusion 13 Now Available With Native Support For Apple Silicon Macs (macrumors.com) 19
VMware today announced the launch of Fusion 13, the latest major update to the Fusion virtualization software. MacRumors reports: For those unfamiliar with Fusion, it is designed to allow Mac users to operate virtual machines to run non-macOS operating systems like Windows 11. Fusion 13 Pro and Fusion 13 Player are compatible with both Intel Macs and Apple silicon Macs equipped with M-series chips, offering native support. VMware has been testing Apple silicon support for several months now ahead of the launch of the latest version of Fusion.
With Fusion 13, Intel and Apple silicon Mac users can access Windows 11 virtual machines. Intel Macs offer full support for Windows 11, while on Apple silicon, VMware says there is a first round of features for Windows 11 on Arm. Users who need to run traditional win32 and x64 apps can do so through built-in emulation. Fusion 13 also includes a TPM 2.0 virtual device that can be added to any VM, storing contents in an encrypted section of the virtual machine files and offering hardware-tpm functionality parity. To support this feature, Fusion 13 uses a fast encryption type that encrypts only the parts of the VM necessary to support the TPM device for performance and security. The software supports OpenGL 4.3 in Windows and Linux VMs on Intel and in Linux VMs on Apple silicon.
With Fusion 13, Intel and Apple silicon Mac users can access Windows 11 virtual machines. Intel Macs offer full support for Windows 11, while on Apple silicon, VMware says there is a first round of features for Windows 11 on Arm. Users who need to run traditional win32 and x64 apps can do so through built-in emulation. Fusion 13 also includes a TPM 2.0 virtual device that can be added to any VM, storing contents in an encrypted section of the virtual machine files and offering hardware-tpm functionality parity. To support this feature, Fusion 13 uses a fast encryption type that encrypts only the parts of the VM necessary to support the TPM device for performance and security. The software supports OpenGL 4.3 in Windows and Linux VMs on Intel and in Linux VMs on Apple silicon.
So this is where they're putting their effort (Score:3)
They're certainly not bothering to even vaguely keep up with modern Linux kernel versions so you can actually have a currently updated Linux host for vmware.
Re: (Score:2)
I ran into this problem too, and I found the answer in https://github.com/mkubecek/vm... [github.com]
Now when I update my kernel (on Ubuntu) I have to go here and make; sudo make install and then reboot so that vmware works with the kernel.
I'm still trying to figure out how to avoid the reboot, it seems that modprobing vmmon and vmnet isn't enough.
Re: (Score:2)
I did that, but it was flaky sometimes. I consequently switched over to kvm with libvirtd and virt-manager, which doesn't have the graphics performance (though you can passthrough if you want) but seems to be very solid. This is working out pretty well for me what with Proton and all.
M1 sucks (Score:3)
Re: (Score:2)
Hence, why get and use Intel Macs for now.
M1: great for native ARM, okay for Mac Intel apps (Score:4, Informative)
That's because it's not an extra layer; Rosetta II is not an emulator. It's a code re-generator and translator; it builds an ARM code executable directly using the Intel code as a guide the first time you try and run an Intel executable. Once that's done, every time you use the application or driver, you're directly running ARM code, not Intel code.
The resulting executable is not as good as native — the CPU architectures are too dissimilar for that — but it is remarkably quick. It is much faster than any software emulation can be.
A VM system such as VMWare's utilizes hardware virtualization, where the host processor is used directly to run the target machine image except when it hits hardware which has to be emulated or where drivers can't directly take over the existing hardware due to the native OS already having control of it. With Intel executables, and an ARM processor running the show, that can't work. The only path out of there is for Apple to (somehow) run Rosetta II or a related technology ahead of any virtualization operations so that the entire VM ends up translated / re-generated and can run directly as ARM. So far, that's not been even hinted at. By anyone who would know, anyway.
There's also a potential pitfall here. Apple arbitrarily discontinued the original Rosetta I, leaving all their own PowerPC applications out in the cold — even though this cost their customer base a lot of money via a complete loss of all previously purchased software. The idea that Apple will work to support Intel Windows and/or Linux codebases with Rosetta II or anything related may be... optimistic. It's certain they could; it's not at all certain they will.
Emulation, as VMWare is currently offering for Intel-under-ARM, will only be able to achieve a fraction of the native performance. Which is a killer for anything that requires real time response, and also for anything that falls below the user's level of tolerance for applications that are things the user can choose to wait to let finish.
And while ARM-based Windows with ARM-based applications and drivers can work in a VM, again, most people are possessed of a large collection of native Intel applications. Very low performance will be the norm for them in the kind of VM system(s) we're talking about here. They're not going to be happy for the most part.
Linux — potentially, at least — could end up better off, because Linux has a well established "we can build for any architecture we have a compiler for and the source code" production record, and for much of linux and linux applications, the source code is directly available. Something that is not true for either the Mac or Windows. The only real sticking point there is that the VM engine itself needs to be pretty good about supporting the lowest level machine images for a modern Linux to function properly. It's pretty early in the game for that, but VMWare has achieved at least somewhat passing grades in the past, so it might yet be an attainable goal.
I'm watching this pretty carefully, because I build real time applications for Mac and Windows; losing real time VM capability means that all the Windows work will have to be done on an actual Windows platform, which complicates things; it increases hardware costs and also butts up against physical space constraints for me.
Re: (Score:1)
Seems M1 VM is fine then, the problems are elsewhere. Windows ARM being trash, and emulation of another architecture are separate matters to me.
Re: (Score:2)
So why were people raving about them in the first place?!
Re: M1 sucks (Score:3)
Why would Apple open up Rosetta 2 like that? Itâ(TM)s a transition tool and undoubtedly has a limited lifespan. For now, Iâ(TM)m happily sticking with my Intel MBP and waiting until at least the third gen or later Apple Silicon laptops to be released. Thanks to all the first and second gen buyers for helping iron out the issues. In time the ARM support of the rest of the software I need will catch-up.
Re: (Score:2)
Overall, I'd say that if you need to run x86/amd64 code, get a decent PC. However, for an architecture which was pretty much designed for phones and USB toasters, what has been done with ARM is pretty good. Any cross-platform emulation is going to be slow, and Rosetta 2 is as good as it gets. It could be Bochs style emulation... which would be more secure, but you will definitely see the performance drop.
I don't emulate programs... I emulate tasks. For example, when doing code with Vagrant, I change the
Re:M1 sucks when you don't understand anything (Score:2)
You can only VM ARM based OS's, which is fine for a few linux VM, but windows 11 ARM is utter trash, especially when emulating x86 code it gets like ~pentium 3 performance.
False. You absolute *can* run Intel-based OS on M1 (and apparently you already are if you're emulating an Intel processor), just like you can run ARM-based OS on Intel, but in each case the non-native processor must be emulated, but no one anywhere ever expects emulated processors to perform at native processor speeds. And if you're running Windows 11 ARM on M1 there is no need to emulate anything, and others are reporting decent performance. [reddit.com] Since you believe you are emulating, even as you deny emulation o
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Final fact is, if rosetta 2 can pass x86 calls to ARM via ANY means, it should be expanded to support passing an x86 VM through to the ARM hypervisor. It SHOULD be trivial, but Apple has no financial interest in giving people pesky things like "choice".
Re: (Score:2)
Final fact is, if rosetta 2 can pass x86 calls to ARM via ANY means, it should be expanded to support passing an x86 VM through to the ARM hypervisor. It SHOULD be trivial, but Apple has no financial interest in giving people pesky things like "choice".
Rosetta 2 does not support x86, only x86_64, and it only translates Intel binaries to native. Emulating hardware is very complex and slow because there is a lot overhead in emulating storage devices, console output devices, ethernet devices, keyboards, and the entire CPU. Rosetta 2 can not ever support kernel extensions or vector processor calls because Rosetta 2 is not emulating an Intel processor. , it merely translates code. It is not trivial nor even possible to emulate hardware at native processor per