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.
Moderator: Thread moved to the Workstation Pro area since v16 is released.
Thanks a lot for your great comments here. We will review your comments and see how to make the optimization and enhancements in subsequent releases.
Please see my comments on some of your qeustions.
1. how to user regular docker.exe
For now, you could start up a new termial without executing "vctl kind", the the PATH of current terminal would inherit the system path. if "vctl kind" got executed, the PATH of current terminal would be changed and vctl kind related binaries would be added in the front.
2. I tried the scenario that use workstation UI to open the kind-control-plane.vmx, It was failed to run into the UI crash issue. Workstation UI doesn't support to do any operation in the vm that vctl started, so you will see a blank screen when you try to open kind-control-plane.vmx by manual. if you could reproduce this crash issue, could you please tell the steps in details?
Thanks again and feel free to let us know if you have any comments/concern here.