Solidworks: activation license mode is not supported in this virtual environment (Qemu-KVM)

Michal Sokolowski asked:

The question is not around Solidworks actually, so please continue to read.

The whole idea of virtualization is to be hardware independent. Before our eyes a whole new dependency level is being created – affixment to the hypervisor.

As far as I know searching in a way to find a workaround of this problem is not violation of the Solidworks license and local law in my country.

My client and I want to activate Solidworks Products on KVM virtual machine. For some weird reasons (Hyper-V and VMware are supposed to be well tested 🙂 they (developers) of Solidworks 2015 PDM don’t want their products to be activated (last 2014 version worked just fine) on Qemu-KVM.

http://www.solidworks.com/sw/support/11168_ENU_HTML.htm
http://www.solidworks.com/sw/support/11168_ENU_HTML.htm

I am using:

setup

As you can see it’s KVM-based VM with Windows 2012 and with Solidworks PDM installation.

Question:
What else can they check if I am running my VM in Qemu-KVM besides checking:

  • MAC address(es) of VM’s Ethernet adapter,
  • Device driver labels,
  • CPU model,
  • ACPI tables.

I am going to rule out the above mentioned things in next few hours, but I’d like to know if You have any other ideas.

Solution:

It turns out they validate two things:

  1. As Michael Hampton correctly pointed there’s - cpu,kvm=off option

to disable the CPUID 0x40000000 leaf.

  1. ACPI Tables on the guest.

Relevant parts of qemu command line parameters:

-cpu host,kvm=off -smbios type=0,vendor=LENOVO,version=FBKTB4AUS,date=07/01/2015,release=1.180 -smbios type=1,manufacturer=LENOVO,product=30AH001GPB,version=ThinkStation P300,serial=S4M88119,uuid=cecf333d-6603-e511-97d5-6c0b843f98ba,sku=LENOVO_MT_30AH,family=P300

Libvirtd config file syntax:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>acm-server</name>
  <uuid>d0e14081-b4a0-23b5-ae39-110a686b0e55</uuid>
  <memory unit='KiB'>81920000</memory>
  <currentMemory unit='KiB'>81920000</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <os>
    <type arch='x86_64' machine='pc-1.1'>hvm</type>
    <boot dev='hd'/>
    <bootmenu enable='yes'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
... Please notice there is no CPU definition on the top.
  <qemu:commandline>
    <qemu:arg value='-cpu'/>
    <qemu:arg value='host,kvm=off'/>
    <qemu:arg value='-smbios'/>
    <qemu:arg value='type=0,vendor=LENOVO,version=FBKTB4AUS,date=07/01/2015,release=1.180'/>
    <qemu:arg value='-smbios'/>
    <qemu:arg value='type=1,manufacturer=LENOVO,product=30AH001GPB,version=ThinkStation P300,serial=S4M88119,uuid=cecf333d-6603-e511-97d5-6c0b843f98ba,sku=LENOVO_MT_30AH,family=P3
  </qemu:commandline>
</domain>

As a proof, now it wants to activate:
with hack

My answer:


Most current hypervisors that run on Intel hardware use CPUID leaves 0x40000000 et seq. to pass information about the hypervisor from host to guest.

KVM, Xen, VMware and Hyper-V all use this method.

This is in addition to the hypervisor feature flag set in CPUID leaf 0x1, which indicates that the machine is a virtual machine.

It’s therefore trivial for a program which can call the CPUID instruction to determine whether it is running under one of these hypervisors.

Recent versions of KVM include a command line option to disable the CPUID 0x40000000 leaf, -cpu kvm=off.


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.