4 ms·

Too little too late. And, on x64 I switched to Parallels because I had problems installing the most recent macOS on several machines. It's clear that VMware h

by e40 4y ago

Too little too late. And, on x64 I switched to Parallels because I had problems installing the most recent macOS on several machines. It's clear that VMware has hampered their ability to support their products (bugs and time to get this release out). It's disappointing, because I like the UI of VMware more than Parallels (yes, probably because I used VMware for many years).

nottorp 4y ago
It probably depends on your use case. You seem to run Mac OS inside Mac OS? On my end I've tried Parallels but my use case involves a lot of passing USB devices to a Windows or Linux VM and VMWare has been much better for that. Although... the point is moot now. I bought a new amd box for running the x86 stuff, in preparation to moving my OS X machine to Mx when I feel brave enough.
- e40 4y ago
  Yes, I do a lot of macOS inside macOS, but I do Windows and Ubuntu, too. The macOS support was just horrible in the last 1-2 years. I had purchased copies for 3 machines and I couldn't get stuff to work on any of them.
tzs 4y ago
I don't like that Parallels requires a subscription to get more than 8 GB of RAM in a virtual machine so I'll be sticking with VMWare Fusion when I get an Apple Silicon Mac. That's assuming that I decide that I actually need such a product. Most of my use of VMWare Fusion on my Intel Mac is to run Linux VMs. I recently have switched to using Docker for that. The only real snag was that I want services running in a Docker container to be reachable from Mac processes on the same port they would be on when deployed on a real server somewhere. E.g., if I've got a server that would be foo.com when live on a real server that I'm testing locally in a container, I want it to appear at some_ip:443 on my Mac, not on something like localhost:8443 that Docker maps to port 443 in the container. That turned out to be not too difficult to deal with by using Wireguard. Specifically, Wireguard between the Linux VM that Docker Mac creates to run containers and the Mac. If Docker Mac works as well on Apple Silicon I might be able to just stick with that and not need either VMWare or Parallels.
- ammanley 4y ago
  I might be reading this wrong, but is this something where you could launch your containerized app running on whatever port, and map it to `localhost:443` using something along the lines of `docker run -p 127.0.0.1:443:<whatever port in the container> My-App-Image` ? (might need sudo). I read this as wanting to have <your IP>:443 proxy to the container. Hope I'm not crazy.
  - tzs 4y ago
    The problem with "-p 127.0.0.1:443:<whatever port in the container>" is that there is already something on 127.0.0.1:443. If I were running Docker on Linux this would not be a problem. I'd simply use bridged networking in the container which would give the container an IP that works for things running on the Linux host. To access something on <whatever port in the container> I'd then just use <container IP>:<whatever port in the container>. Docker Mac runs a Linux VM and then runs your containers on that Linux VM. Bridged networking there just bridges the containers to the Linux VM. The container's IP is not visible to the Mac, just to the Linux VM. So I'm using Wireguard to tunnel between the Linux VM and the Mac, so that the container IPs end up visible on the Mac. In case anyone else finds this useful, here are details of my setup. • I've got a Docker network name "Mynet" that I put containers on with statically assigned IP addresses (e.g., "--network Mynet --ip 10.11.12.10"). Mynet has gateway 10.11.12.1. It was created with this command: docker network create --driver=bridge --subnet 10.11.12.0/24 --ip-range=10.11.12.128/25 --gateway=10.11.12.1 Mynet IP address 10.11.12.128-254 are dynamically allocated to containers that are run with "---network Mynet" but not assigned a static IP. 10.11.12.2-127 can be used for static IPs. • On the Wireguard tunnel, I've given my Mac IP 10.11.0.2 and the Docker Linux VM IP 10.11.0.3. • The Mac IP address on my home network is 192.168.0.2. • I've made a Docker alpine image, which I named alpine-wg, that is just the base alpine image with the Wireguard tools installed. The Docker Mac Linux VM has Wireguard kernel support built in, so you just need an image with the tools in order to configure it. • I've generated key pairs for the Mac and the Linux VM. • Here is my Wireguard conf file for the Mac (stored on Mac as ~/wg/mac/wg.conf). [Interface] Address = 10.11.0.2/32 PrivateKey = <Mac private key> ListenPort = 51820 # docker VM [Peer] AllowedIPs = 10.11.0.3/32, 10.11.12.0/24 PublicKey = <Linux VM public key> • Here is the Wireguard conf file for the Linux VM (stored on Mac as ~/wg/linux-vm/base.conf): [Interface] Address = 10.11.0.3/32 ListenPort = 51820 PrivateKey = <Linux VM private key> [Peer] AllowedIPs = 10.11.0.2/32 PublicKey = <Mac public key> EndPoint = 192.168.0.2:51820 PersistentKeepalive = 25 • Commands to run on the Mac: # bring up the tunnel sudo wg-quick up /Users/tzs/wg/mac/wg.conf # take down the tunnel sudo wg-quick down /Users/tzs/wg/mac/wg.conf • Aliases on the Mac to bring up, take down, and show the tunnel on the Linux VM: alias linux-wg-up='docker container run -it --rm --privileged --pid=host -v ~/wg/linux-vm:/wg alpine-wg nsenter -t 1 -u -n -i wg-quick up /wg/base.conf' alias linux-wg-down='docker container run -it --rm --privileged --pid=host -v ~/wg/linux-vm:/wg alpine-wg nsenter -t 1 -u -n -i wg-quick down /wg/base.conf' alias linux-wg-show='docker container run -it --rm --privileged --pid=host -v ~/wg/linux-vm:/wg alpine-wg nsenter -t 1 -u -n -i wg show'
ianlevesque 4y ago
The graphics support in particular sounds like a total mess: > For Graphics, Fusion 13 sports OpenGL 4.3 in Windows and Linux VMs on Intel, and in Linux VMs on Apple Silicon. > On Intel, Windows continues to enjoy DirectX 11 graphics, and Fusion continues to support eGPU devices for incredible performance using some of the fastest GPU’s available. > On Apple Silicon, Fusion can deliver OpenGL 4.3 with blazing fast 3D hardware acceleration to arm-based Linux virtual machines with Linux kernel 5.19 or greater. So if I am reading this correctly, Windows on Apple Silicon doesn't have accelerated 3D at all? And even on Intel they are 10 full years behind with no support for DirectX 12. I guess this is what happens six years after firing the entire team, once you can no longer coast on past innovations. https://arstechnica.com/information-technology/2016/01/vmware-fusion-workstation-team-culled-in-company-restructure/ https://arstechnica.com/information-technology/2016/01/vmwar...
- Raymonf 4y ago
  Other than Hyper-V, what hypervisor can paravirtualize DirectX 12?
scrlk 4y ago
VMware laid off their US based Workstation/Fusion team a few years back and moved development over to China. The China based team was then laid off in 2021 with development moving to India.
- geraldwhen 4y ago
  This is the move for any business intending to cut costs to near 0 and ride out a user base subscription to inevitable product death. I’ve seen this happen multiple times; there are whole companies with this as their business model.
- mixmastamyk 4y ago
  Why did they do that? Is it because VirtualBox and containers destroyed the market for them? Not enough money to bother competing with Parallels?
deleted 4y ago
[deleted]

by e40 4y ago

nottorp 4y ago

It probably depends on your use case. You seem to run Mac OS inside Mac OS? On my end I've tried Parallels but my use case involves a lot of passing USB devices to a Windows or Linux VM and VMWare has been much better for that. Although... the point is moot now. I bought a new amd box for running the x86 stuff, in preparation to moving my OS X machine to Mx when I feel brave enough.

e40 4y ago
Yes, I do a lot of macOS inside macOS, but I do Windows and Ubuntu, too. The macOS support was just horrible in the last 1-2 years. I had purchased copies for 3 machines and I couldn't get stuff to work on any of them.

tzs 4y ago

I don't like that Parallels requires a subscription to get more than 8 GB of RAM in a virtual machine so I'll be sticking with VMWare Fusion when I get an Apple Silicon Mac. That's assuming that I decide that I actually need such a product. Most of my use of VMWare Fusion on my Intel Mac is to run Linux VMs. I recently have switched to using Docker for that. The only real snag was that I want services running in a Docker container to be reachable from Mac processes on the same port they would be on when deployed on a real server somewhere. E.g., if I've got a server that would be foo.com when live on a real server that I'm testing locally in a container, I want it to appear at some_ip:443 on my Mac, not on something like localhost:8443 that Docker maps to port 443 in the container. That turned out to be not too difficult to deal with by using Wireguard. Specifically, Wireguard between the Linux VM that Docker Mac creates to run containers and the Mac. If Docker Mac works as well on Apple Silicon I might be able to just stick with that and not need either VMWare or Parallels.

ammanley 4y ago
I might be reading this wrong, but is this something where you could launch your containerized app running on whatever port, and map it to `localhost:443` using something along the lines of `docker run -p 127.0.0.1:443:<whatever port in the container> My-App-Image` ? (might need sudo). I read this as wanting to have <your IP>:443 proxy to the container. Hope I'm not crazy.
- tzs 4y ago
  The problem with "-p 127.0.0.1:443:<whatever port in the container>" is that there is already something on 127.0.0.1:443. If I were running Docker on Linux this would not be a problem. I'd simply use bridged networking in the container which would give the container an IP that works for things running on the Linux host. To access something on <whatever port in the container> I'd then just use <container IP>:<whatever port in the container>. Docker Mac runs a Linux VM and then runs your containers on that Linux VM. Bridged networking there just bridges the containers to the Linux VM. The container's IP is not visible to the Mac, just to the Linux VM. So I'm using Wireguard to tunnel between the Linux VM and the Mac, so that the container IPs end up visible on the Mac. In case anyone else finds this useful, here are details of my setup. • I've got a Docker network name "Mynet" that I put containers on with statically assigned IP addresses (e.g., "--network Mynet --ip 10.11.12.10"). Mynet has gateway 10.11.12.1. It was created with this command: docker network create --driver=bridge --subnet 10.11.12.0/24 --ip-range=10.11.12.128/25 --gateway=10.11.12.1 Mynet IP address 10.11.12.128-254 are dynamically allocated to containers that are run with "---network Mynet" but not assigned a static IP. 10.11.12.2-127 can be used for static IPs. • On the Wireguard tunnel, I've given my Mac IP 10.11.0.2 and the Docker Linux VM IP 10.11.0.3. • The Mac IP address on my home network is 192.168.0.2. • I've made a Docker alpine image, which I named alpine-wg, that is just the base alpine image with the Wireguard tools installed. The Docker Mac Linux VM has Wireguard kernel support built in, so you just need an image with the tools in order to configure it. • I've generated key pairs for the Mac and the Linux VM. • Here is my Wireguard conf file for the Mac (stored on Mac as ~/wg/mac/wg.conf). [Interface] Address = 10.11.0.2/32 PrivateKey = <Mac private key> ListenPort = 51820 # docker VM [Peer] AllowedIPs = 10.11.0.3/32, 10.11.12.0/24 PublicKey = <Linux VM public key> • Here is the Wireguard conf file for the Linux VM (stored on Mac as ~/wg/linux-vm/base.conf): [Interface] Address = 10.11.0.3/32 ListenPort = 51820 PrivateKey = <Linux VM private key> [Peer] AllowedIPs = 10.11.0.2/32 PublicKey = <Mac public key> EndPoint = 192.168.0.2:51820 PersistentKeepalive = 25 • Commands to run on the Mac: # bring up the tunnel sudo wg-quick up /Users/tzs/wg/mac/wg.conf # take down the tunnel sudo wg-quick down /Users/tzs/wg/mac/wg.conf • Aliases on the Mac to bring up, take down, and show the tunnel on the Linux VM: alias linux-wg-up='docker container run -it --rm --privileged --pid=host -v ~/wg/linux-vm:/wg alpine-wg nsenter -t 1 -u -n -i wg-quick up /wg/base.conf' alias linux-wg-down='docker container run -it --rm --privileged --pid=host -v ~/wg/linux-vm:/wg alpine-wg nsenter -t 1 -u -n -i wg-quick down /wg/base.conf' alias linux-wg-show='docker container run -it --rm --privileged --pid=host -v ~/wg/linux-vm:/wg alpine-wg nsenter -t 1 -u -n -i wg show'

ianlevesque 4y ago

The graphics support in particular sounds like a total mess: > For Graphics, Fusion 13 sports OpenGL 4.3 in Windows and Linux VMs on Intel, and in Linux VMs on Apple Silicon. > On Intel, Windows continues to enjoy DirectX 11 graphics, and Fusion continues to support eGPU devices for incredible performance using some of the fastest GPU’s available. > On Apple Silicon, Fusion can deliver OpenGL 4.3 with blazing fast 3D hardware acceleration to arm-based Linux virtual machines with Linux kernel 5.19 or greater. So if I am reading this correctly, Windows on Apple Silicon doesn't have accelerated 3D at all? And even on Intel they are 10 full years behind with no support for DirectX 12. I guess this is what happens six years after firing the entire team, once you can no longer coast on past innovations. https://arstechnica.com/information-technology/2016/01/vmware-fusion-workstation-team-culled-in-company-restructure/ https://arstechnica.com/information-technology/2016/01/vmwar...

Raymonf 4y ago
Other than Hyper-V, what hypervisor can paravirtualize DirectX 12?

scrlk 4y ago

VMware laid off their US based Workstation/Fusion team a few years back and moved development over to China. The China based team was then laid off in 2021 with development moving to India.

geraldwhen 4y ago
This is the move for any business intending to cut costs to near 0 and ride out a user base subscription to inevitable product death. I’ve seen this happen multiple times; there are whole companies with this as their business model.
mixmastamyk 4y ago
Why did they do that? Is it because VirtualBox and containers destroyed the market for them? Not enough money to bother competing with Parallels?

deleted 4y ago

[deleted]