我正在与提供基于服务器的应用程序的供应商合作，该应用程序需要激活授权。 有两种select，基于软件的许可和基于硬件（USB-dongle）的激活。 在基于VMware的服务器上运行应用程序软件的环境中，使用硬件或软件许可证密钥有什么优缺点？ USB硬件许可证密钥将被插入其中一个： https ： //www.digi.com/products/usb/anywhereusb
有两个应用程序正在许可：供应商：Iconics软件：GENESIS32 SCADA平台供应商：罗克韦尔自动化软件：FactoryTalk（RSLinx）
这是供应商对硬件密钥的偏好的推理：
我们发现硬件密钥比软件密钥更稳定，特别是在虚拟机环境中。 软件密钥通常连接到计算机的硬盘驱动器或NIC ID。 任何时候这个数字改变（硬盘驱动器故障，虚拟机重新configuration等）许可证丢失，需要在制造商的帮助下重新加载。 今天的许可证是通过互联网完成的，大多数服务器都没有互联网接入，因此处理许可问题已成为一大难题。 硬件密钥适用于虚拟机，因为它们不驻留在虚拟机上。 如果您发生映像故障或其他服务器故障，则可以复制新映像，指向许可证密钥，然后启动并运行。
硬件密钥添加了一个额外的故障点。 我已经看到他们rest。 当他们rest时，你不能login到你的刷卡系统，并给新的人访问build筑物。 叹
如果您有select，请务必使用软件密钥。 FlexLM（比较常见的许可证服务器之一）例如是一个真正的痛苦，但一旦启动并运行，您不必担心。 使用硬件密钥，您不得不担心密钥失败，USBAnywhere失败，USBAnywhere软件失败等。
我已经使用了USBAnywhere设备，它们已经非常稳定，但是我仍然更喜欢软件密钥10次。
请参阅： 跨平台支持networking连接的USB集线器？
所有其他条件相同，您需要软件密钥的灵活性。 使用USBencryption狗进行这项工作会降低系统的可移植性，并且不会提供太多的好处。
许多软件制造商已经明智地认识到人们正在全面虚拟化，并希望利用其类似vMotion的function。 如果给出一个基于软件的授权scheme的select，使用它！
软件密钥通常连接到计算机的硬盘驱动器或NIC ID。 任何时候这个数字改变（硬盘驱动器故障，虚拟机重新configuration等）许可证丢失，需要在制造商的帮助下重新加载。
计算机的NIC ID（也称为MAC地址）不应在VM环境中更改。 另外，您通常可以分配MAC地址以匹配许可证文件中的MAC地址。 MAC地址通常可以在操作系统中伪装（我在Linux上这样做）。
依赖于硬盘的硬编码ID的许可证服务器正在寻求麻烦 – 驱动器故障是不可避免的，RAIDarrays是常见的，并且常常replace硬盘是正常的。
看来，USBencryption狗将更容易失败，然后几乎任何其他。
我们pipe理大约20台许可证服务器，所有这些都依赖于MAC地址或更简单的机制。
我意识到你的问题是在VMware环境中，但我认为一般问题与其他虚拟化平台（包括Hyper-V）有关。
我最近对老化的服务器进行了虚拟化，这个服务器依赖于基于硬件USB的许可密钥运行了一个服务，发现它们在Hyper-V环境中本身不能工作。 Hyper-V部署指南有这样的说法：
No access to a physical COM port is available from a virtual machine. 您可以将虚拟机的COM端口连接到命名pipe道，但显然不是实际的串行端口。 显然这主要是一个debuggingfunction。 您可以使用COM端口redirect器（如KernelPro的以太网USB）为虚拟机提供对串行端口的访问。
另外，如果您希望在主机服务器上安装授权密钥，则授权密钥的软件和驱动程序需要支持安装在Window Server上，而在我们的服务器核心上则需要。
我最终在工作站上安装了授权密钥和软件，然后将其作为该网站的“授权服务器”使用。 这增加了十个不同的东西，现在可以打破这个软件。 一个基于软件的许可证密钥会为我节省很多麻烦，我怀疑是一个更可靠的解决scheme。