A software consultancy promoting cheating? How scandalous. Do bear with me though.
Recently I had occasion to repurpose a machine for use as an integration environment. This is basically where a bunch of software that works in concert will be put, so that the team can verify that, “Yes, it does in fact, work together.” These kinds of environments allow QA, Dev, and Product management to interact with the integrated software: fully demo-able and testable.
The machine I was working with previously ran virtual machines (VMs) in Virtualbox under Windows 10 Professional. A part of the requirement was that those VMs still be available afterwards. Ultimately, we wanted Docker Enterprise in Windows Server 2019, and in so doing have actual containers, instead of the VM-based non-enterprise “containers” of Windows 10.
The initial plan was to take 1 day each for backup, installation and restoration. The first hiccup was that Windows Server 2019 did not support the network card used by this machine. A quick google search later and a solution to that was found by a fellow awesome team member.
Unfortunately, after getting the network drivers installed and then installing Docker Enterprise, I was unable to run the Virtualbox VMs. The docker containers ran great however, so we were 80% of the way there. The VMs not running didn’t exactly come as a surprise, because Hyper-V was installed before Docker Enterprise. I was aware that Virtualbox did not work when Hyper-V was installed. I had intended to convert the VMs to a Hyper-V format and run them that way. After converting one successfully and trying to run it, the VM ran, but didn’t start the OS.
You see I had made a grave error. I assumed. I assumed that Hyper-V had support for the operating system running in the VMs because it was similar to linux. But this was no linux VM. I had previously confirmed that Hyper-V did successfully run with the special version of linux we were using. Unfortunately, it did not work with our real-time operating system image. I was stuck, and without a solution. Fear and trepidation snuck in. Panic was knocking at the door. Thankfully, close to a decade of experience managing libvirt, ESXi and other virtualization software, plus lots of manual reading gave me a pretty good understanding of hypervisor types.
You see (briefly) virtualization software uses a CPU feature (VT-x) to speed up virtualization, but only one application can use that feature at a time. I knew that Hyper-V was not an application (like Virtualbox) that would relinquish VT-x when it wasn’t running—it always had it (in VM parlance, it was a level 1 hypervisor). But I also knew that docker containers for windows server did not need Hyper-V. Hyper-V was used when running linux “containers” or versions of windows with a different kernel (it’s a whole thing, see the image below for a sample Docker for Windows compatibility matrix).
So then came the cheating. The “cheat” was to uninstall Hyper-V, and document things (so the team knew why linux images, or older windows images would not run on this server). The “right” solution—setting up another server—would have taken much more time and quite frankly not provided much benefit. Nothing we run on the integration environment required Hyper-V today. When running linux software we used VMs. If we wanted to run linux containers, other machines were available to do that.
Yes, technical debt was created (we can’t run certain containers), but this was acceptable technical debt. These were not containers we had planned to run. The (good) debt was taken on now, and gave us time to pay it back later and do the time sensitive work needed now, when speed of delivery and accuracy was of the utmost importance.
I share this story not only to illustrate how I approach, and solve problems, but also to point out that as developers, we don’t always need to take the conventional solution. Once you know and understand the tools you work with well enough, you can start taking shortcuts that do actually save you time (instead of just pushing out problems until much later).
I also wanted to share because sometimes there is no magical incantation of search terms that brings you exactly to your solution. It also shows that yes, as developers we make mistakes (assumptions about Hyper-V) but we can also fix those mistakes when we remain calm and put in the work to look for solutions. At some point in time, the guy posting the novel solution for problem X had to figure it out because no one around him knew how, and there’s no reason why that can’t be you.
Never give up, cheat sometimes and whatever you do, always document your work! Three months later when you’ve forgotten everything you’ve done and why, your brain will thank you for that Markdown document in source code explaining it all. And so will your fellow developers, if they ever run into that particular problem.
Good luck, and God bless!