Software Licensing in Virtual Machines: Clones, Moves and VDI

Software licensing in virtual machines has two opposite failure modes. A copied image can preserve the identity of an activated installation, while a legitimate migration can change enough inputs to look like a new device. A useful policy handles both without assuming every virtual machine is fraud.

Start by deciding what you sell: a persistent installation, a named user or a concurrent session. Then choose the matching registration and renewal rules. A hardware fingerprint is an application identifier, not proof that a unique physical computer exists.

Virtual hardware has a lifecycle

A VM can expose a hostname, virtual processors and a virtual system identifier. Those values depend on image preparation and the hypervisor. VMware's UUID guidance distinguishes keeping an identifier when moving a VM from generating one for a copy. That does not mean every application reads that UUID or that it is an unforgeable identity.

Azure's image guidance distinguishes generalized images, which remove machine-specific information, from specialized images that retain it. Generalizing an operating system is not a promise that every application's seed, license cache or session token has been removed. Review your own application state before distributing a template.

On Linux, systemd documents machine-ID preparation for generic images and treats the raw identifier as confidential. OS identity is useful context for image administrators; it is not a reason to expose raw host identifiers or to assume PermitCore's default helper reads that file.

Know what your SDK's device ID means

PermitCore's eight SDKs accept a device ID. Their normal default-helper paths hash a persisted local seed; most also include runtime-specific host, OS, architecture or processor inputs. The portable Unity default hashes its persisted seed, while its optional engine-based helper uses Unity's device identifier. Defaults differ by runtime and platform: do not assume two SDKs on the same VM produce the same ID.

A copied profile or disk can preserve a seed. A hostname, processor allocation, profile or cache-directory change can change the derived identity. The exact effect depends on the helper you use. Plan a controlled identity migration if you change SDK language, helper or storage location in an already-shipped app.

You can supply an explicit device ID when you need a stable deployment identity. Provision it through your application's installation process and scope it to the unit you license. Do not put one fixed ID in every image, generate a new ID on every API call, or trust a user-editable name as an authenticated person. The SDK is not a VM-attestation service.

Cloning and snapshot rollback

A node-locked license recognizes the reported device ID. If two clones present the same ID, the server cannot reliably distinguish them from a legitimate repeat request by that identity. Hashing the same copied inputs does not add uniqueness. A copied offline token can also remain usable on a clone that reproduces its signed device binding and other required context.

Prepare a golden image before activating a customer license. Keep license keys, signed caches and active floating tokens out of distributable templates. Provision each actual licensed instance after deployment, then test the resulting IDs. Do not erase an existing customer's identity as a routine update: that can strand its registration and consume a replacement slot.

Restoring a VM snapshot restores local application state too. It does not roll back the licensing server's records, and it does not grant a new signed offline deadline. Nevertheless, an offline verifier running entirely inside a restored or modified guest is not a universal defense against host-controlled clock and state rollback. Use bounded offline authority and a reconnect policy that fits the risk; do not promise that signatures make a customer-controlled VM unpatchable.

Migration should have a recovery path

For a persistent VM, preserve the supported application identity across an in-place move when the licensed installation is meant to remain the same. Test the move first: a processor or hostname change can affect a default fingerprint even when the disk is preserved.

If the identity legitimately changes, use an authorised device-removal or support workflow, then activate the replacement. Keep the original key and entitlement where appropriate. Portal authority depends on the configured access policy; possession of a shared key is not the same as verified ownership of a customer organisation.

Removing a registration frees its capacity. It does not uninstall the old copy or instantly invalidate every previously issued offline proof. Your application must enforce the relevant registration, validity and signed deadline. The license-transfer guide and customer portal reference explain the available controls.

Choose a policy for each environment

• Persistent desktop or VM: a node-locked key can fit a stable installation. Publish its device allowance and provide a supported replacement process.
• Non-persistent VDI: consider floating concurrency when the commercial unit is simultaneous use. Provision a distinct identity for each intended concurrent consumer rather than copying one identity across the pool.
• Named-user cloud desktop: authenticate the person in your application. A VM ID or hostname alone cannot establish who the person is or how many people share it.
• Disconnected VM: distribute trusted verification keys and a device-bound signed token with a deliberate expiry. Plan renewal and recovery before disconnecting.
• Containers or CI workers: define whether the unit is a runner, job or concurrent worker. Use the CLI licensing guide; a changing container hostname is not automatically a useful customer identity.

The team-seat guide separates these customer capacities from the vendor account's monthly activation pool. Neither an admin-team invitation nor a pool allowance automatically defines a customer's VM entitlement.

Floating seats need distinct consumers and enforced deadlines

PermitCore floating checkout creates or renews a session for the license and device ID. A repeated checkout for an existing device renews that session; it does not reserve another independent seat. Clones sharing the same device ID or session token can therefore undermine a policy that assumes every process is a distinct consumer.

Give each intended consumer a properly provisioned identity. Check out before protected work, heartbeat while it runs, stop on denied renewal or the returned expiresAt, and await check-in after work stops. An unconfirmed check-in is not proof that the seat has been released; crash recovery relies on expiry. Offline validation does not renew a floating session.

Use the returned deadline rather than assuming a fixed duration: the license's access deadline can shorten a grant. The floating lifecycle reference includes the actual SDK operations and cancellation pattern. Availability and caps depend on your plan; the SDK does not automatically wrap every application's protected work.

A VM-friendly PermitCore setup

1. Describe the licensed unit and allowed migration, shared-desktop and offline scenarios in your sales terms.
2. For a persistent installation, configure a node-locked license with the intended device cap. For concurrent use, configure floating mode and its session cap instead of treating activation count as concurrency.
3. Choose and persist the application identity after image deployment. Keep a clean template free of customer license and session state.
4. Use the activation flow where registration is required. Check the result, expected product and features; successful validation alone does not create an activation or a floating session.
5. Implement the chosen renewal or offline-verification rules. Prepare public trust configuration before disconnecting; private signing material belongs in the vendor's secure recovery process.
6. Document how an authorised customer requests a migration reset and what happens to the old installation. Separate license access, support eligibility and payment status.

Test moves and copies separately

Use your own test licenses and disposable images. Check a normal reboot, preserved-disk migration, changed CPU or hostname, fresh profile, independent clone and snapshot restore. Inspect the reported ID and server-side registration or session result without logging keys or tokens.

Also test a full device cap, two genuinely distinct floating consumers, a copied consumer identity, denied heartbeat, crash without check-in, expired offline proof and reconnect after revocation. Record the limitation when copied identity remains indistinguishable; an honest recovery and risk policy is more useful than a “blocks all VMs” checkbox.

Continue with device activation, hardware-ID tradeoffs and offline verification.