The docs pointed me here to express my thoughts on vctl. So here goes. I've got VMware Workstation 16.0.0 and vctl 1.1.0 on a Windows 10 2004 host.
I've been eagerly awaiting Workstation 16's release because of this "run containers in Workstation" feature. It's one of the main reasons I've chosen to purchase an upgrade.
The first thing I noticed is vctl is using the old Docker syntax. For example, `docker container list` and `docker image rm` are much simpler to remember and teach than `docker ps` and `docker rmi`. I grant vctl is only v1, but only supporting the old syntax makes it feel like Docker 1.13. In theory it should be easy(ish) to shim the other cli arguments into calling the same underlying functions.
Supporting kind right out of the gate is brilliant. But it makes me curious: What's the DOCKER_HOST and DOCKER_CERT_PATH env vars I need to get regular docker.exe to run? Knowing vctl merely proxies to containerd running in the VM it just started, I wonder if I could get more compatibility with existing tools by connecting directly. (For comparison, run `minikube docker-env` and it rigs up regular docker.exe to minikube's docker-compatible pipe.) With these values, I could also easily rig up VS Code Remoting into the VMware-hosted container runtime, and rig up a dozen other GUI and CLI tools, unleashing a whole new volume of opportunities.
`vctl kind` downloading kind.exe and kubectl.exe is brilliant. But both are a version out of date. Perhaps vctl kind could use the GitHub releases API to grab the latest version? I'm also curious what would happen if I did download the latest and stick them earlier in my path. Are these official releases? Or are they VMware look-alikes? Creating a fake docker.exe shortcut is completely cheating. Because the command set is only sort-of compatible, and because the console output is formatted so differently, I'd rather this wasn't even an option. (It's self-documented if I must also change my script from docker.exe to vctl.exe.) All else being equal, I'd rather the real docker.exe could shim into place. But barring this option, no docker.exe is better.
I ran `vmrun list`, grabbed the path into ~\.r\vms\kind-control-plane\ and was curious. I went into VMware Workstation GUI, File -> Open, pointed it at this VM, and wonderfully froze VMware Workstation. (Oops.) Either the open dialog should block me from doing this or it should show me only the VM details, never giving me the console window. The crash is an unfortunate answer.
All-in-all, I see great promise here. It is indeed really rough, but I grant it's only a v1, so I can forgive. I could see this turning really great in time.
