Software can't detect that it is running on a VM - change to Qemu64?

[Leo007]

Hi all,

I have a problem where a specific software, running on a Windows Server 2019 VM can’t detect the System as a virtual one, and as a result, the license of the software cannot be assigned correctly.

 

Hypervisor is Unraid 6.8.3.

 

I am in contact with the development team of the software and they did some testing and told me that their software uses the CPU ID flags to check if it is a virtual machine or not. That brings me to the conclusion that the CPU mode “Host Passthrough” (VM settings) causes the “problem”.

 

I am not very familiar with the deeper virtualization technology, but I know that “CPU Host Passthrough” is recommended for better performance.

 

There is certainly a reason why “Host Passthrough” is the default setting. What else are the benefits over Qemu64? Stability? As this is productive System with some apps running on it, can I easily switch to Qemu64 or are further problems to be expected?

 

I definitely want to use the better technology and don’t want to switch to Quemu64 if it brings any important downsides. In the end, the software development team has to come up with another solution to identify the systems…

 

Greetings,

Leo

[bastl]

I'am curious which software development team forces their software to ONLY run inside a VM. Usually it's the other way, if a hypervisor is detected a license server gives an error and the software is unusable. Not sure which CPU feature are used by that software. By using a “CPU Host Passthrough” flag CPU features are directly used and not emulated by software like if you use a emulated "virtual CPU" like "Qemu64".

 

With emulation you will always see a decrease in performance compared to a software directly running on hardware. If a software doesn't really need specific hardware features like for example AES encryption modules or AVX for acceleration there will be no big differences in performance emulated vs. running on physical hardware, but literally every software today benefits from directly using CPU features in some way.

 

The main os in the guest system and also most apps will benefit from better performance by directly accessing the host CPU. The only reason I can think of distributing a software in this way is to preconfigure a VM which runs on almost all host configurations, independent from the feature sets the host CPU provides. Emulate everything and it runs everywhere basically.

 

The only software I every stumbled accross only running inside a VM or want an specific virtual CPU flag is a Kuka robot controller software. It only runs inside a VMware VM with a specific flag for the CPU. Performance is kinda garbage starting the preconfigured untuned VM, even increasing the assigned RAM or core count will break the internal license server.

 

At the end it's up to the developers to limit their software on which configs they think it should run and what systems they won't allow to be used.

 

Take it or leave it!

[Leo007]

On 4/16/2021 at 4:13 PM, bastl said:

I'am curious which software development team forces their software to ONLY run inside a VM.

Hey bastl, thanks for your reply. Obviously I should have explained it in more detail... It's not that the software won't work. However, it does not accept a license for a virtual machine. It would work with a license for a physical machine, but the licenses for a VM are much cheaper. It's all about the license costs.

 

The software is Acronis Cyber Backup which is used to back up special files from a database. In order to be able to work at the file level, the software needs an agent on the VM. The host system and the VM itself do not have to be backed up via the software - so there is no software installed on the host system. In such a use case, the agent on the VM checks what kind of system it is, informs the cloud console (also license server) and is provided with a corresponding license. In this case, unfortunately, this does not work because, as I now know, only the CPU ID flags are used as a criterion to check whether it is a VM or not.

 

Knowing this, the question for me was whether it would be possible to switch to Quemu64 with an existing system without any problems and what disadvantages or perhaps advantages this would bring.

 

 

[bastl]

On 4/17/2021 at 10:49 PM, Leo007 said:

disadvantages or perhaps advantages

As I said before, performance might be an issue, depending on the programs running inside the VM.

 

Also to be noted you can edit the xml of a VM and change the CPU flag to emulate a specific CPU type. For example the following I have in one of my VMs to emulate a Skylake CPU

  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Skylake-Client</model>
    <topology sockets='1' dies='1' cores='6' threads='1'/>
    <feature policy='require' name='topoext'/>
    <feature policy='disable' name='hypervisor'/>
    <feature policy='disable' name='pcid'/>
    <feature policy='disable' name='hle'/>
    <feature policy='disable' name='erms'/>
    <feature policy='disable' name='invpcid'/>
    <feature policy='disable' name='rtm'/>
    <feature policy='disable' name='mpx'/>
    <feature policy='disable' name='spec-ctrl'/>
  </cpu>

 

If your current Acronis Client is running on a specific CPU and the license is bound to this CPU it might be possible to emulate that same CPU inside the VM and the license might still work. Maybe check the libvirt or qemu documentaion. Quick search for "<cpu match='exact'>" and i found a couple examples from fedora https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/ch15s13s03.html They should work for VMs in Unraid.