Virtualization really helps. We have a lot of weird software which requires hardware dongles, but they're all USB dongles and they're all virtualized, one of the DC racks has a few U worth of just USB socket -> dongle wired up so that if we spin up a VM it can say "Hey, give me a USB socket with a FooCorp OmniBloat dongle on it" and get one unless they're all used.

would certainly be interested to learn more about this

> Turns out some of the software running on it had some weird licensing checks tied to the hardware so it refused to start on the new server.

This is around the time when you call that one guy on your team that can reverse engineer and patch out the license check.

Interoperability exception might allow this in exigent circumstances when you do have a valid license, but I wouldn’t do this without running it by the software vendor whose license you are using. In a recovery situation, you’ll probably need to be on the phone a lot, so I can see how you might think it’s quicker to bypass the license check, but that is one person giving some or all of their attention just to that. Disaster recovery isn’t a one person job unless that one person was the whole team anyway, so I think this idea needs to be calibrated somewhat to expectations.

This is a nightmare kind of discovery. I had a similar one, but fortunately, it wasn't as impactful.

This is why I like docker, if you keep the sources, you recover no matter what (at least until the "no matter what" holds water)

> This is why I like docker,

my understanding is that docker would not have helped in that scenario

it really depends on the scenario but if the application was dockerized and they had an image, it would be just starting it again, somewhere else.

Possibly with the same network settings if the licensing check was based on that.

But of course it can easily go south, though testing the recovery of a container based off an image and mounted volume is simple and quickly shows you if it works or not.

But of course it may work today but not tomorrow because the software was not ready for Y2K and according to it we are in the XX century or something and the license is 156 years ... young. Cannot allow this nonsense to proceed, call us at <defunct number>

IT is full of joy and happiness

> it really depends on the scenario

yeah and that scenario was clear:

> Turns out some of the software running on it had some weird licensing checks tied to the hardware so it refused to start on the new server.

"hardware" does not mean "bare metal". It could be a MAC, a serial number or similar things that may be linked to a generic or clonable value in virtualization.

but docker isn't virtualization, you understand this, right ?

To some extent, yes -- having developed apps that were dockerized, and having managed virtualization systems (ESXi and similar), as well as docker engines.

I am not sure I see your point, though.