
VMware Fusion 11.5: Now with Container Support - ingve
https://blogs.vmware.com/teamfusion/2020/05/fusion-11-5-now-supports-containers.html
======
wdb
This sounds cool so it's not creating a virtual machine anymore to run Docker
like stuff?

I have tried it out but seems to require a Pro license:

ERROR failed to set up port forwardings: failed to get container network:
error code:exit status 255, message:Error: There is no valid Professional
license to run this command

Bummer, can't use it then

~~~
mikeroySoft
Using the -p flag tells the vmnet to create a NAT rule, and yes only the Pro
license can do that, but you can still fire up the container on the local
vmnet.

So the way vctl works is that it launches a new VM for each container, so the
container gets a dedicated internal IP address on a newly created VMnet. So
like a 172.x.x.x or 192.168.x.x, and you just access the port directly from
the host mac. The -p would make the VM's port reachable via the host's IP
address.

In your vctl command, just omit the -p flag + value and it should spin it up.
Then run vctl ps to see the IP of the appliance vm. You would then access it
from the host Mac via the vm's IP, like: 192.168.243.130:1234

~~~
wdb
Hmm, okay, thanks, if it works on my laptop it would be cool. I don't really
care that the port is available from other systems.

------
vaxman
No thank you, VMware off-shored development and canned the local Fusion devs
and quality has suffered (CVEs, system crashes, etc) as it's lowly competitor
pulled way out ahead and the whole company is indirectly owned by DELL now.
(DELL isn't exactly an Apple fan.) Also, Fusion 11.5 only runs on Mojave or
higher, which is an issue for some older servers (like the trashcans).

Meanwhile Apple is deprecating Kexts and obviously shifting to ARM, so better
to do all this inside of Linux running on the Apple Hypervisor.framework
(Parallels) while looking around at non-ARM alternatives.

~~~
mikeroySoft
Okay, let’s talk about that.

That was worst moment of my career. It still leaves a sour taste in my mouth
just talking about it. I loved working with those folks.

No one in VMware was happy about that decision, (the internal uproar was
incredible...) the exec who made the call had no idea what they were doing
with this. (Newer to VMware...)

Thank goodness the execs responsible for that have absolutely nothing to do
with Fusion or Workstation now, and haven’t for some time.

We moved out of that group (end user computing) and into the core platform
(I.e. vSphere) group in 2018 as a response, had renewed investment (vmmon
engineers working on this had to stop/delay working on ESXi features to
deliver our User Level Monitor changes to support the Huper-V APIs...), and
new direction.

Frankly I couldn’t be happier with where we’re at, other than for the entire
old UI team to still be with us.

Sore subject for me tho. They are my friends, and I had to carry on like
nothing happened, or I would have been out the door just like them (and
summarily sent back to Canada, I was on a visa still at the time...).

I opted to work my ass off internally to make sure this would never happen
again, and that we had a solid plan for the future.

This project (vctl) as well as hyper-v mode support in Workstation, are the
first fruits of that work. We’re in the right home, the team is innovating
well, and our engineering and product leads are long time WS/Fusion folks. We
can’t undo the past, but we can try do our best to do the right thing for our
customers. (Hence all the free .5 updates instead of paid ones for the past
couple of years...)

Dell doesn’t get in the way. At all. Ever. They’re wholly uninterested in our
tiny business.

And yah, it’s harder and harder to support older version of macOS when Apple
is so aggressively making kernel level changes that we have to engineer for.

We’ll be supporting hypervisor.framework soon (tech preview after 10.16 beta
drops). We also have ESXi on ARM, incidentally engineered with the original
engineer for Fusion, so we’re ready if that happens. We’ve seen no sign of
Apple giving up on x86 tho (for real...)

------
ValentineC
With this, is it now possible to Dockerise macOS apps, the way Jessie Frazelle
does for Linux [1]?

[1] [https://blog.jessfraz.com/post/docker-containers-on-the-
desk...](https://blog.jessfraz.com/post/docker-containers-on-the-desktop/)

~~~
mikeroySoft
That wasn't the intended use case, but it might be possible. I haven't tried
personally, but if someone attempts something like that and they run into a
blocker I can certainly take a look.

------
yoz
How does performance compare to Docker Desktop? My employer has a complex
Compose setup for building our server infra, and it's pretty taxing to run.

~~~
mikeroySoft
Startup and build performance of containers are both expected to be slower
than docker, but it varies by how much. Mostly a byproduct of limitations with
9pfs and multi-threading, and we're working on it.

Once running in a vmx process it consumes only as much memory as it needs,
with a configurable upper limit, whereas docker reserves 3GB off the bat by
default. So a bare nginx container will eat up like 250MB of memory, but in DD
it's a part of the already consumed 3gb.

We haven't finished our more exhaustive testing just yet, but we think it
should result in better battery life.

That said, we don't have compose support yet. It's something we're working on
in a way that we're hoping goes a little beyond the spec that we're seeing
today.

