Open topic with navigation
A good example of a Virtual Machine (VM) guest environment is where the Windows operating system is running in an isolated environment in OS X (using software like VMWare Fusion or Parallels). Although copy protection is designed to prevent copying a license from one machine to another, its effectiveness is often limited when the license machine happens to be a virtual machine. This is due to the fact that the virtual hardware (and the device drivers for that hardware) does not change after copying the virtual machine from one host computer to another.
The way your application should react to a virtual machine guest environment will largely depend on the nature of your application and the systems on which it is run. For example, if your application is a typical desktop GUI application that should be activated once on each licensed computer, then you might opt to prevent your application from running in this type of environment. However, if your application needs to run in large office environments where employees use virtualized desktop environments, or if your application provides some kind of service (especially one which requires high-availability, such as a web application or web service), you may need to allow the application to run in these types of environments. If your application falls into the latter category, then you should take further consideration into the types of system identifiers used by your application. For example, if your application is a web application or web service, then one option may be to include the fully qualified host and domain name as a system identifier (you can use the ServerHostNameIdentifierAlgorithm for this purpose). You might also want to evaluate other pieces of information that might make for suitable, custom identifiers.
PLUSManaged makes it very easy to detect virtual machine guest environments via the VirtualMachineValidation class. The code below provides an example of how this can be used in your license implementation class (i.e. in the Validate method).
As mentioned in the introduction of this topic, copy protection is limited in how well it can prevent a protected application from running in a copied virtual machine guest environment. If you need to license virtual machine guest environments regardless of the limitations,there are some reasonable measures you can take to help prevent this sort of thing from happening, which is what is explained here.
PLUSManaged includes a number of SystemIdentifierAlgorithm implementations that can help you better identify both physical machines and virtual machine guests. This section will explain what algorithms are most effective for virtual machine guest environments, and the behavior you can expect from each of the algorithms.
With physical computers, the BiosUuidIdentifierAlgorithm is useful for uniquely identifying a motherboard, and this is also useful for uniquely identifying an specific virtual machine guest. This means that if a user creates two new virtual machine guests, which we will call Guest A and Guest B, and installs any operating system on them, they will receive different identifiers for each unique guest. However, if the user were to make a copy of either guest, you might not see a different UUID for that copy of the guest. If you are using something like VMWare ESX Server, you should see a unique UUID even for the copy, as it requires a unique UUID to manage each individual guest it hosts.
The identifiers generated with the HardDiskVolumeSerialIdentifierAlgorithm use data that is generated when a partition is formatted. Since this is usually done when installing the operating system, this value is usually different between different virtual machine guests. However, as with physical machines, use of system imaging software (such as Backup Exec System Recovery) can duplicate an operating system installation, including the volume's serial number. With this limitation in mind, this algorithm is best used when accompanied by another algorithm such as the BiosUuidIdentifierAlgorithm.
The MAC (or physical) address of Network Interface Cards (NICs), which may be identified with the NicIdentifierAlgorithm, is also useful for identifying both physical machines and virtual machine guests. This is because two machines cannot have connectivity on the same network when they share the same MAC address. While this may be useful, it should be noted that most hypervisors allow you to configure the virtual machine guests to use Network Address Translation (NAT), which essentially hides the virtual machine guest behind a separate network. In other words, two virtual machines sharing the same MAC address with bridged connections will not work on the same network, but they may work on separate hosts when using NAT.
The ProcessorIdentiferAlgorithm provides information about the processor's name, vendor/manufacturer, and version (which includes the model and stepping). In virtual machine guest environments, this information about the processor generally matches the host (although it is sometimes possible for further isolation to be used, which is uncommon since it usually has a negative impact on performance and features for the virtual machine guest). Using this information can help you prevent scenarios where a user copies a virtual machine guest created with VMWare Workstation on a PC to a Mac host running VMWare Fusion, for example. However, if your application needs to allow the guest to float to different hosts (i.e. when using VMWare ESX with VMotion), then this data should change, and is counter-productive to use for uniquely identifying the licensed system.