jmellander's Posts

After writing the above, I saw a bunch of postings about the upgrade path from 11 to 13 and realized it seemed somewhat risky if it was done the right way. Then I realized I could try it on my private computer first (which also has Catalina, and where I have another license of Fusion Pro version 11.) So I purchased the upgrade at 99 EUR, only to realize that the license key generated only works for Fusion 13 and is not backwards compatible with version 12... You mentioned it should be down-gradable, @dempson , is there a process for that which I should explore? I opened a support ticket, but the lady that contacted me said the system did not given them the option to generate another key. Thanks.

Thanks dempson. I'm now at the point of upgrading to macOS Monterey after all (mainly for other reasons than VMware Fusion). And I then need to upgrade VMware Fusion anyway. However, I'm looking for details on the hypervisor change that you mention. Is it documented in any detail somewhere? In fact I didn't see anything about it in the release notes for 12.2. I'd like to know if any of the "advanced networking" changes would affect my use, as I do quite a bit of networking between my VMs on my host. I'm just not sure if it's considered advanced in this context or not.

Bumping this one. (And now that Fusion 13 is out, it turns out it's not an immediate option for me as I'm on macOS Catalina.) So my hope is set to Fusion 12 I guess. Does anyone know the answer to my question? (Edit: I realize now that Fusion 12 requires BigSur, so I guess I'm stuck until I'm ready to upgrade macOS.)

Thanks  @Mikero . I now understand the networking with vctl a bit more. So basically the container host is mapped to all interfaces on the Mac, and does a port-forwarding to the container IP and port regardless of which interface you address. Also, the traffic is souce-NAT:ed with the external IP as the source. I managed to kind of work around this by looking at the properties configured of the vmnet adapter assigned to the container host. There I could see that DHCP was enabled, and that NAT and connecting the local host was enabled too. Disabling the NAT was not an option, as the container start was aborted once that's detected. But I could disable the DHCP, And then I enable DHCP server mode on one of my VMs (a firewall acting as a router), and put it on another IP, next to the local Mac's IP. After this, the containers are provided an IP from my firewall, which means I have more control of the IP assigned, as well as can set the default gateway to be that of the firewall. And now I can route traffic straight the container, without NAT. And by omitting the usual portmapping when starting the container, I can basically also prevent any traffic from coming in that way. The only really odd thing I've observed so far is that _if_ I try to use the portmapping on the Mac host, just before the first TCP segment is sent, there is an ARP request sent for the container IP address, but with the sender IP of my firewall, but the sender MAC and source MAC of the local Mac host's interface... (this is detected as an IP conflict by Wireshark, given that another MAC address claims to have the IP of the firewall/gateway. vctl ps    is by the way still able to detect what IP was assigned to the container. What remains to be seen is how persistent the MAC address assignment to the container is, and whether IP address reservation in my DHCP server will work over time, so that my services end up on predictable IP addresses. Edit: One showstopper I relized in the end is that when I do a vctl system stop and vctl system start, a new vmnet adapter is created... Not sure if that's due to the original vmnet adapter already existed and was used.... Bummers! Any ideas on how to tweak or hack things to get around this?

Mikero​ Certainly. Attached is the docker and docker-compose files. There are also two file system files, but I'm guessing these are not as relevant, and also too big to post here. For running the image as a container, there is also a shell script which results in a command like below (with the variables replaced of course). docker run  -itd $dk_memory $dk_env --name $dk_name $dk_portmap $dk_extra $dk_caps $dk_image But if I interpret the logs correctly (and based on what I expect) vctl is not trying to run the image at this stage. (That would be a later step.) Thanks Jonas