VM环境中的硬件许可证密钥与软件许可证密钥

我正在与一家供应商合作，该供应商提供了基于服务器的应用程序，该应用程序需要激活许可。有两个选项，基于软件的许可和基于硬件（USB加密狗）的激活。在基于VMware的服务器上运行应用程序软件的环境中，使用硬件或软件许可证密钥的优缺点是什么？USB硬件许可证密钥将插入以下之一：https : //www.digi.com/products/usb/anywhereusb

有两个已获得许可的应用程序：供应商：Iconics软件：GENESIS32 SCADA平台供应商：罗克韦尔自动化软件：FactoryTalk（RSLinx）

这是供应商偏爱硬件密钥的原因：

我们发现，硬件密钥比软件密钥更稳定，尤其是在VM环境中。软件密钥通常附在计算机的硬盘驱动器或NIC ID上。每当此数字更改（硬盘驱动器故障，VM重新配置等）时，许可证就会丢失，需要在制造商的帮助下重新加载。当今的许可是通过Internet完成的，并且大多数服务器都无法访问Internet，因此处理许可问题已成为头疼的问题。硬件密钥对于VM来说效果很好，因为它们不驻留在VM上。如果出现映像故障或其他服务器故障，则可以复制一个新映像，指向许可证密钥，然后就可以正常运行了。

硬件密钥增加了一个额外的故障点。我见过他们破裂。当他们确实休息时，您将无法登录刷卡系统，也无法向新用户提供进入建筑物的权限。叹

如果可以选择，请始终输入软件密钥。例如，FlexLM（较常见的许可证服务器之一）确实让人头疼，但是一旦启动并运行，您就不必担心。使用硬件密钥，您必须担心密钥失败，USBAnywhere失败，USBAnywhere软件失败等。

我曾经使用过这些USBAnywhere设备，它们的性能非常稳定，但我仍然希望软件密钥在10次中占10次。

请参阅：跨平台支持网络连接的USB集线器吗？

千篇一律，您需要软件密钥的灵活性。使用USB软件狗进行此工作会降低系统的可移植性，并且没有太大的优势。

许多软件制造商已经意识到人们将进入完全虚拟化并希望利用其类似于vMotion的功能这一事实。如果提供了基于软件的许可方案的选项，请使用它！

软件密钥通常附在计算机的硬盘驱动器或NIC ID上。每当此数字更改（硬盘驱动器故障，VM重新配置等）时，许可证就会丢失，需要在制造商的帮助下重新加载。

在VM环境中，计算机的NIC ID（也称为MAC地址）不应更改。此外，您通常可以分配MAC地址以匹配许可证文件中的MAC地址。通常可以在操作系统中伪造MAC地址（我在Linux上做到了）。

依靠硬盘驱动器的硬编码ID的许可证服务器提出了问题-硬盘故障不可避免，RAID阵列很常见，并且不时更换硬盘是正常的。

USB加密狗似乎比其他任何东西更容易出现故障。

我们管理大约20个许可证服务器，所有这些服务器都依赖于MAC地址或更简单的机制。

我知道您的问题是在VMware环境中，但我认为一般问题与其他虚拟化平台（包括Hyper-V）有关。

我最近虚拟化了一个老化服务器，该服务器运行的服务依赖于基于硬件USB的许可密钥，并且发现它们不能在Hyper-V环境中本地运行。《 Hyper-V部署指南》说：

No access to a physical COM port is available from a virtual machine.

您可以将虚拟机的COM端口连接到命名管道，但显然不能连接到实际的串行端口。显然，这主要是调试功能。您可以使用COM端口重定向器（例如KernelPro的USB over Ethernet）为虚拟机提供对串行端口的访问。

另外，如果您希望将许可密钥安装在主机服务器上，则需要支持将许可密钥的软件和驱动程序安装在Window Server上，在我们的情况下，则需要支持安装在Server Core上。

我最终在工作站上安装了许可密钥和软件，然后将其用作该站点的“许可服务器”。这增加了大约十种不同的东西，这些东西现在可以破坏该软件。基于软件的许可密钥可以为我省去很多麻烦，并且我怀疑这是一个更可靠的解决方案。