VMware Workstation “hostWin32.c:559” error

When running VMware Workstation 16 or 17 on a Windows host, you perhaps encounter the following error:

PANIC: VERIFY bora\vmx\main\hostWin32.c:559

This error happens when you have a Windows VM running and then try to launch a second Windows VM. As soon as the second machine boots into the desktop/login, it crashes, and the machine stops.

Luckily, this VMware forum post gave me a workaround that solved the issue. Hopefully, it will be helpful for you as well.

I am using an Nvidia graphics adapter and have set the “Max Frame Rate” and “Background Application Max Frame Rate” settings via the Nvidia Control Panel to values other than “Off”. This is what caused the issues for me.

The solution: Simply add a program-specific customization for vmware.exe, ensure both settings are set to “Off” in the customization, and you should be good.

A Eulogy for VMware Project Nautilus

Do you remember the hype in 2020 when VMware announced their own OCI-compliant, Docker-compatible container support in their desktop virtualization solutions? I even wrote about it in 2021 after it had some time to mature.

So where is Project Nautilus in 2023, a good three years later? Dead, in the grave.

In 2021, I called vctl “a promising disappointment”, but in 2023 I will have to change that title to “an ambitious stillbirth”. After three whole years and a new major (paid) VMware Workstation version, vctl is still exactly where it was back in 2020.

When people poke VMware staff about this on Twitter, the response pretty much shuts the door on any further development:

I wish I could say it were in a better state. […] We’re taking the time to address this in a more holistic way.

Now, just in case you do not know what “taking the time to address this in a more holistic way” means in plain old English: There are no plans to put another second of development time into it, but marketing says it is a bad look to deprecate it after just one major version, especially since VMware already removed Shared VMs from the desktop virtualization solutions.

This is such a shame. VMware had an admittedly early but incredibly compelling feature in the pipeline that perfectly complemented its core technology and gave developers another reason to love Workstation or Fusion.

Rest in peace, Project Nautilus. I bemoan the waste of potential and awesomeness.

VMware Workstation – Containers with vctl

I never understood why people think Docker is a big thing. To me, it always seemed to solve a problem that does not exist by adding layers of complexity which inevitably always introduce new problems and bugs.

If you wanted to isolate processes, why not use jails or zones? “But Tsukasa”, people sneered at me with mild amusement in the past, “you don’t understand. It’s about the ease of replacing software!”. Yeah, you can do that without Docker, it’s called package management.

Somewhere along the line, the OCI was founded and at least there was some kind of standardized way of handling containers.

Enter VMware Workstation in the middle of 2020. Coming to us courtesy of a technical preview, VMware shipped the new vctl container CLI it plucked from VMware Fusion. And I really wanted to love it, because the idea behind it is good – but…

A Promising Disappointment

I am a VMware guy. After more than a decade with VMware Workstation, I really dig the features. Yes, you can probably achieve similar results with other virtualization solutions – but none make it as easy as VMware. Yes, call me indolent and a fanboy, if you must. So imagine my joy when VMware announced their container CLI.

No more need to install the Hyper-V role, no more fiddling with some wonky plugins – just a clean, supported product that does what Docker does, but with VMware’s hypervisor in the back. One product to be the definitive all-out solution for my desktop (x86) virtualization needs.

VMware creates a new virtual machine in the background that acts as a host for the containers. This machine does not show up on your usual list of running VMs. Instead, it will show you the active containers. Don’t click on them though, the Workstation UI does not really know what to do with containers and you will end up with a botched tab of nothingness.

Since vctl is using VMware’s hypervisor, all the good stuff is already in place and familiar to me. Network configuration is dead simple and I have all the tools to explore/manage the container VM.

The performance is also top-notch, so what could I possibly complain about?

The integration and the polish. vctl creates an alias to docker, so you can issue both a vctl ps or docker ps and get the same result. Unfortunately, vctl does not shim all the commands and parameters Docker has, meaning that a lot of tooling and cool integration simply does not work. Want to use VSCode’s Remote Container extension with VMware? Bad luck, the command does not reply in the expected fashion because it does not understand all the parameters.

This is incredibly disappointing because the container feature in Workstation is so close to being a fantastic proposition in a time where VMware sunsets some long-standing features (cough, Shared VMs, cough, Unity on Linux, cough).

It does what it says – and nothing more… yet!

Please don’t misunderstand: The feature does what it advertises to do. I can easily author a Dockerfile and build it with vctl – without having to install Docker. This by itself is already a godsend because it reduces the amount of software I need to install on my workstation.

But I cannot help but wonder how cool it would be to have a (parameter-compatible) drop-in replacement for Docker from VMware as part of the software I use for full virtualization anyway. And give me a docker-compose, while you are at it. Thanks.