Which VM CPU model to choose to have same CPU id string even after PVE upgrade?

[alexc]

Hello,

I used to run KVM VM with some licensed software in it (there is Debian and the software run in it). When the VM was setup the CPU was set to kvm64 and never changed.

The software itself used to bind its license to hardware list of the PC (that is, VM), and the problem is, if I somehow update PVE version, the license is broken. When I once asked what kind of hardware changed the licensed software support replied that CPU ID string they collect changed in such a way:

QEMU Virtual CPU version 1.0 Family 6 Model 2 Stepping 3 PhysID: 0 CoreID: 0 Cache size: 4096 KB

to

QEMU Virtual CPU version 1.0.50 Family 6 Model 2 Stepping 3 PhysID: 0 CoreID: 0 Cache size: 4096 KB

(see version change?)

This is why I have to run PVE 2.2 (!) nowadays and I hate this since new hardware is unsupported.

I can re-license the software, but quite rare and as I want to do major PVE upgrade to 6.2 soon I want to change CPU to the one that never change its id string.

Please advice, which CPU should I use so its id string won't change on PVE upgrade?

 

[H4R0]

Select "host" as cpu, it will forward your hypervisor cpu information to the guest. This is the only real option you have. However if you replace the server or upgrade the cpu you will have the same problem. If you run a cluster all nodes (cpu) must be identical.

IMHO your software distributor should not include the cpu id.. There are better ways to generate a HID which works with virtualization.

 

[alexc]

IMHO your software distributor should not include the cpu id.. There are better ways to generate a HID which works with virtualization.

I have to politely admit this is quite old software but we have to use it nevertheless. And it won't tell the difference between VM and physical host. These guys used to bind to both hardware and software, so OS version and all packages have to be intact, too. You can imagine how happy we are to keep it running

Looks like they do concatenate CPU strings together to get whatever string they think is unique.

Select "host" as cpu, it will forward your hypervisor cpu information to the guest. This is the only real option you have. However if you replace the server or upgrade the cpu you will have the same problem. If you run a cluster all nodes (cpu) must be identical.

I'd like not to rely on host's CPU info since we can upgrade (replace) the CPU, or whole server for whatever reason. This is why I hope I can use some "virtual" CPU type so no change can be seen whenever I upgrade the PVE or server hardware itself.

But what's strange, I can't find (say, at cat /proc/cpuinfo output) CPU string with version, it says like this:

model name : Common KVM processor

not like

model name : QEMU Virtual CPU version 1.0.50

How can I get CPU string with all that extra details to check?

Thank you!

 

[H4R0]

I have to politely admit this is quite old software but we have to use it nevertheless. And it won't tell the difference between VM and physical host. These guys used to bind to both hardware and software, so OS version and all packages have to be intact, too. You can imagine how happy we are to keep it running

Looks like they do concatenate CPU strings together to get whatever string they think is unique.



I'd like not to rely on host's CPU info since we can upgrade (replace) the CPU, or whole server for whatever reason. This is why I hope I can use some "virtual" CPU type so no change can be seen whenever I upgrade the PVE or server hardware itself.

But what's strange, I can't find (say, at cat /proc/cpuinfo output) CPU string with version, it says like this:

model name : Common KVM processor

not like

model name : QEMU Virtual CPU version 1.0.50

How can I get CPU string with all that extra details to check?

Thank you!

Yeah i totally get you, you might want to wait for a answer from the proxmox staff.

Maybe one of the cpu options besides host is guaranted not to change.


It doesnt look like proxmox allows to controll all settings like kvm would, you could hide the cpu information otherwise.

My last idea is to bind the vm to a specific qemu version, with this the kvm cpu flag should not change.

So instead of "pc" or "q35" in your vm configs at /etc/pve/qemu-server/id.conf

You could static link with "pc-i440fx-5.0" or "pc-q35-5.0"

List available settings with "qemu-system-x86_64 -machine help"

 

[LnxBil]

I had a similar problem with such old software and found a very neat solution: nested virtualization. Just run your PVE 2.2 host inside of a PVE 6.2 VM and try if the software still works. So you can have all your legacy software, but encapsulated in two layers of virtualization.

 

[alexc]

I had a similar problem with such old software and found a very neat solution: nested virtualization. Just run your PVE 2.2 host inside of a PVE 6.2 VM and try if the software still works. So you can have all your legacy software, but encapsulated in two layers of virtualization.

Nice move, never given a try, will consider. Really good approach when no other way works!

What's your experience, if there big speed overhead because of that?

 

[LnxBil]

What's your experience, if there big speed overhead because of that?

Yeah, that depends: The system is still slow, but comparable to the old hardware from yester-decade. So, you will most probably not gain any speed improvements, but it hugely depends on what the application does. Storage for example will be much faster if you put it on SSD if it was previously on old harddisks.