A Proxmox VM fingerprint is the set of identifiers a guest can read that say “I’m a VM on Proxmox.” SMBIOS UUID, manufacturer string, virtio disk serials, MAC prefix, and the CPUID hypervisor bit are the main ones. Some you can change with qm set, some need args, and one you can’t change at all.
What the guest actually sees
Run dmidecode inside the VM and you’ll see the SMBIOS data. On a stock Proxmox VM the manufacturer is QEMU, the product name is Standard PC (i440FX + PIIX, 1996), and the UUID is a random value Proxmox generated when you created the VM. The serial number is blank by default. All of that is guest-visible and none of it is secret.
The virtio disk serial is also visible. If you used scsi0: local-lvm:vm-100-disk-0, the guest sees a serial like QM00001. That’s Proxmox’s default naming, and it’s a dead giveaway. The MAC address starts with BC:24:11, which is the OUI registered to Proxmox. Any network scanner that knows that prefix knows it’s a Proxmox VM.
Then there’s the CPUID hypervisor bit. When a guest runs cpuid and sees the hypervisor flag set, it knows it’s virtualized. That’s the one people try to hide with kvm=off, but on Proxmox that’s not a supported option and it breaks things.
What you can change with qm set
SMBIOS fields are the easiest. Proxmox exposes them directly:
qm set 100 --smbios1 uuid=12345678-1234-1234-1234-123456789abc,manufacturer=Supermicro,product=X11SPL-F,serial=123456789That changes the UUID, manufacturer, product, and serial. The guest’s dmidecode will show whatever you put there. This is the main lever for reducing the VM fingerprint.
Virtio disk serials can be set per disk. In the VM config file /etc/pve/qemu-server/100.conf, add serial= to the disk line:
scsi0: local-lvm:vm-100-disk-0,serial=WD-WCC6Y1234567Then the guest sees that serial instead of QM00001. You can also change the MAC address in the GUI or with qm set 100 --net0 virtio=BC:24:11:AA:BB:CC,bridge=vmbr0, but the OUI still says Proxmox unless you use a different prefix. That’s fine — most real hardware has a random MAC from the vendor’s pool, so pick any other OUI and you’re less obvious.
What you can mask with args
The CPUID hypervisor bit is not exposed by qm set. You have to pass a raw QEMU argument. In the VM config, add:
args: -cpu host,kvm=offThat hides the hypervisor flag from the guest. But it also disables some paravirtualization features, and on Proxmox it’s known to cause problems with Windows guests and nested virtualization. I’d leave it alone unless you have a specific reason. The SMBIOS changes get you 90% of the way there.
What you can’t change
The QEMU version string is baked into the binary. A guest can query the hypervisor vendor and version via CPUID leaves, and it will always report KVMKVMKVM or similar. There’s no supported way to fake that on Proxmox without patching QEMU. Also, the virtio device IDs are fixed — a virtio-net device always has PCI vendor ID 1af4. You can’t change that without using a different device model, like e1000, which has its own telltale IDs.
So the realistic best case is: change SMBIOS to something plausible, set custom disk serials, use a non-Proxmox MAC OUI, and accept that the CPUID hypervisor bit and QEMU version are still visible. That’s enough to fool casual detection scripts but not a determined adversary. For a homelab, that’s probably all you need.
If you’re doing this to run software that refuses to install on VMs, the SMBIOS changes are usually what matters. The cloud-init template approach makes it easy to spin up VMs with these settings already baked in.
