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

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.

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