Hacker News Reader

Comment by e40 | Hacker News Reader

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).

View on HN

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.

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.

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'

I have a similar need for work (k8s instead of docker) and I just use the routing table on my router and `/etc/hosts` files (need domain names fir certificates) works easy.

This was a fascinating read, thank you for sharing. TIL!

EDIT: Is your home IP address for your mac static? Seems like if it was dynamic, this would need to be updated, though I know you can use some simple programs to dynamically inquire for the IP, and then just template it out into the config files before launching, just in case.

It's dynamic as far as the Mac is concerned, but I have my home router's DHCP configured to assign fixed IP addresses to various devices with known MAC addresses including the Mac.

> I want it to appear at some_ip:443 on my Mac, not on something like localhost:8443

You can add hostnames to /etc/hosts if "localhost" bothers you.

Then you map ports to host ports using the -p docker argument.

Solving this with wireguard sounds like super overkill.

The typical case is that I'm testing with client code on my desktop that expects to talk to some particular server, such as db.work.com, on some particular port, say 3306. I don't want to run the client in a VM or container.

I want to run a test version of that server on a VM or in a container, and have that client connect to it, but I do not want to modify the client.

So I want to make an /etc/hosts entry for db.work.com giving the IP address of the VM or container that I'm running the test server in.

That works great with VMWare Fusion. The VM gets an IP address on my Mac, and I use that in the /etc/hosts entry.

That would also work great if I were running Linux instead of Mac OS, because Docker containers on Linux get IP addresses that are visible. I'd just have to put the container IP on the db.work.com /etc/hosts entry.

On Mac Docker runs a Linux VM and then the containers run in that. They don't have IP addresses that are visible to the Mac. For a lot of things that is fine. With the -p argument you can arrange to have a localhost port mapped to some port on the container.

But in my case that doesn't quite cut it. The client wants to connect to port 3306. I can't just map localhost:3306 to the container and put db.work.com in /etc/hosts pointing to 127.0.0.1 because I've already got something on 127.0.0.1 that is using 3306.

Hence Wireguard so that I can have an IP address for the container that is visible on 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.

MacBook Pro M1 Max user here. Yes, Docker Mac works on Apple Silicon.

Make sure to use Docker images built for Arm. M1 Rosetta is good, but is not used for Docker images. If you run Docker images for x86_64 in Docker Mac on Apple Silicon it’s noticeably slower. Whereas running docker images built for Arm is fast.

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.

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.

Why did they do that? Is it because VirtualBox and containers destroyed the market for them? Not enough money to bother competing with Parallels?

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/vmwar...

Other than Hyper-V, what hypervisor can paravirtualize DirectX 12?

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.

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.

Reply on news.ycombinator.com