Hmm, okay, thanks, if it works on my laptop it would be cool. I don&#x27;t really care that the port is available from other systems.

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&#x27;s port reachable via the host&#x27;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&#x27;s IP, like: 192.168.243.130:1234

This sounds cool so it&#x27;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 commandBummer, can&#x27;t use it then

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&#x2F;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&#x2F;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...)

No thank you, VMware off-shored development and canned the local Fusion devs and quality has suffered (CVEs, system crashes, etc) as it&#x27;s lowly competitor pulled way out ahead and the whole company is indirectly owned by DELL now. (DELL isn&#x27;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.

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

With this, is it now possible to Dockerise macOS apps, the way Jessie Frazelle does for Linux [1]?[1] <a href="https:&#x2F;&#x2F;blog.jessfraz.com&#x2F;post&#x2F;docker-containers-on-the-desktop&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.jessfraz.com&#x2F;post&#x2F;docker-containers-on-the-desk...</a>

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&#x27;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&#x27;s a part of the already consumed 3gb.We haven&#x27;t finished our more exhaustive testing just yet, but we think it should result in better battery life.That said, we don&#x27;t have compose support yet. It&#x27;s something we&#x27;re working on in a way that we&#x27;re hoping goes a little beyond the spec that we&#x27;re seeing today.

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

VMware Fusion 11.5: Now with Container Support