Moving an OEM Licence Into a Proxmox VM, and What Moves With It

The Licence Is Already in the Firmware

Plenty of people own a licence for the Fisher-Price OS (Windows) without ever having seen its product key. It came with the machine, and the key lives in that machine’s firmware, in a small ACPI table called MSDM.

Then the machine stops being where the work happens. Either its owner wants that licence in a VM they now rent from you, or the machine itself gets wiped, turned into a Proxmox host, and the copy of the OS it shipped with is wanted back as a VM on top.

Mechanically, it is one QEMU option. That is the problem. QEMU hands any table to a guest without checking it, the guest activates with whatever key it finds, and nothing anywhere in the stack asks whether the licence allows any of it. This post covers what the table is, how to get it into a VM without passing on a corrupt one, what Microsoft’s terms say about moving it, and why a volume licence never goes near it.

What the Table Is

Since OEM Activation 3.0, a PC maker no longer prints the key on a sticker on the bottom of the case where anybody with a phone camera can copy it, and the key goes into the machine’s firmware instead. Microsoft’s factory tooling “injects the product keys into the firmware”, and its validation step checks “that the MSDM table exists” and that its header and entries “comply with the correct formats”¹. A machine set up that way is “activated by using the OA3 DPK in the firmware”². MSDM is an ordinary ACPI table, and on Linux it reads straight off the firmware:

sudo cat /sys/firmware/acpi/tables/MSDM > msdm.bin

The laptop this was written on carries one. 85 bytes.

Microsoft’s published specification defines the standard 36-byte ACPI header with the signature MSDM, and then stops. Everything after the header is a “Proprietary data structure that contains all the licensing data necessary to enable Windows activation”³.

QEMU Will Pass Anything You Give It

QEMU’s -acpitable file= takes the “whole ACPI table from the specified files, including all ACPI headers (possible overridden by other options)”⁴, and the guest then sees an MSDM table exactly as a laptop’s firmware would present it. That was checked with a deliberately fake key. The bytes came out the other side identical, signature to last character.

QEMU refuses nothing. This is what hw/acpi/core.c does with a broken upload⁵:

The guest has no way of telling the difference, and neither do you until somebody opens a support ticket. The first anybody hears of it is a customer whose activation failed.

So if customers upload these, check them before QEMU ever sees them:

#!/usr/bin/env python3
"""Refuse anything that is not a well-formed MSDM table before QEMU sees it."""
import re, struct, sys

t = open(sys.argv[1], 'rb').read()
fail = lambda why: sys.exit(f"{sys.argv[1]}: {why}")

if len(t) < 56:                       fail(f"{len(t)} bytes, too short for an MSDM table")
sig, length = t[:4], struct.unpack_from('<I', t, 4)[0]
if sig != b'MSDM':                    fail(f"signature is {sig!r}, not MSDM")
if length != len(t):                  fail(f"header says {length} bytes, file is {len(t)}")
if sum(t) & 0xff:                     fail("checksum does not sum to zero")
ver, _, dtype, _, dlen = struct.unpack_from('<5I', t, 36)
if (ver, dtype) != (1, 1):            fail(f"version {ver}, data type {dtype}: expected 1 and 1")
if dlen != 29 or 56 + dlen != length: fail(f"data length {dlen}: expected 29")
key = t[56:].decode('ascii', 'replace')
if not re.fullmatch(r'([0-9A-Z]{5}-){4}[0-9A-Z]{5}', key): fail("data is not a 5x5 product key")
print(f"OK  OEM {t[10:16].decode(errors='replace').strip()!r}  key *****-*****-*****-*****-{key[-5:]}")

It never prints the key, only the last group. A product key in a log file is a product key somebody else can use.

Run against a good table and three broken copies of it:

OK  OEM 'EXMPLE'  key *****-*****-*****-*****-EEEEE
bad-sum.bin: checksum does not sum to zero
bad-trunc.bin: header says 85 bytes, file is 70
bad-sig.bin: signature is b'SLIC', not MSDM

Where It Goes, and Who Can Put It There

A product key is a secret. It does not belong anywhere www-data can read, and pmxcfs gives you exactly one place in /etc/pve where it cannot⁶:

At 85 bytes it is nowhere near the 1 MiB pmxcfs file limit⁷:

mkdir -p /etc/pve/priv/msdm
check-msdm.py upload.bin && cp upload.bin /etc/pve/priv/msdm/9000.bin
qm set 9000 --args "-acpitable file=/etc/pve/priv/msdm/9000.bin"

qm set --args replaces the whole line. If the VM already carries SMBIOS or firmware options in args, write them all out together. And because args is root only, this is a job for your provisioning, not something a customer can do from the web interface. That is the right way round. The customer supplies the file, your tooling checks it and attaches it.

The Table Moves a Key, Not a Right

This is where the feature needs a clear head. Moving the MSDM table into a VM moves the key. Not the licence.

Microsoft’s own terms say so, and the lines that matter fit in a table:

The table always comes from the customer’s own licensed machine, never from your hosts. The case that sits squarely inside the wording is the simplest one: the machine the licence was sold with, now running Proxmox, with that same copy of the Fisher-Price OS (Windows) moved into a single VM on it. That is still one instance on one device, and the OEM terms allow that “whether that device is physical or virtual”⁸. A second VM, or another machine, and it is not.

In that one case the customer’s machine and the hypervisor are the same box, so there is nothing to upload and nothing to copy. The Proxmox kernel already exposes the firmware’s MSDM table under /sys/firmware/acpi/tables/, readable by root only, and QEMU on Proxmox runs as root, so it can take the table straight from there:

qm set 100 --args "-acpitable file=/sys/firmware/acpi/tables/MSDM"

Pointing at the live table rather than a copy has two consequences. The path is read on whichever node the VM starts on, so this belongs on a standalone host and not in a cluster: migrate the VM and it either gets that node’s table, a different licence on a different machine, or does not start at all, because QEMU refuses a missing file with can't open file … No such file or directory. And it is one line, which makes it one line to paste onto a second VM. That second VM is the case the terms do not cover, so one VM gets it and no others.

So build the feature. The mechanism is sound, and there are customers entitled to use it; one who bought their licence in Germany may well be among them. But put the entitlement where it belongs: in your terms of service, the customer warrants they hold a licence that covers running it in your VM, and they do it before the upload button does anything. The validator proves the table is well-formed. Nothing proves it is theirs to use.

Volume Licences Never Go Near the Table

Can a customer with a volume licence use the same route? No. There is nothing for the table to carry.

MSDM belongs to the OEM channel and nothing else. Microsoft’s own planning guide says OEM activation “is available only for computers that are purchased through OEM channels and have the Windows operating system preinstalled”¹². Volume licences activate through one of three other models, “Multiple Activation Keys (MAK)”, “KMS” and “Active Directory-based activation”¹², and in every one of them the key is installed in the operating system. Nothing reads it from firmware.

So for a volume customer there is nothing to build on the hypervisor. Their key goes in their image, and your part is the network path: port 1688 to their KMS host, or a VPN to their domain controllers. The MSDM slot stays empty, and it should.

Two things catch people out. The generic key on volume media activates nothing by itself, because “the GVLK doesn’t work unless a valid KMS host key can be found”¹², so a VM built from the customer’s Enterprise ISO with no route home sits unactivated. And a desktop volume licence is not a licence on its own. Volume programmes “cover upgrades to Windows client operating systems only”, and “an existing retail or OEM operating system license is needed for each computer”¹². The volume licence sits on top of a base licence, very often the same OEM one the last section was about, and whether it may run in your VM is still the hosting question in that table, not an activation one.

AVMA earns a line of its own, because it is the one that looks like the answer. It is Microsoft’s way for a host to activate its own server guests, binding “the VM activation to the licensed virtualization host”, and it requires “a Windows Server Datacenter edition with the Hyper-V server host role installed”¹³. Microsoft are plain about the rest: “AVMA doesn’t work with other server virtualization technologies”¹³. On Proxmox, server guests activate through your SPLA keys or through the customer’s own KMS.

Nothing in the Stack Checks the Paperwork

Every layer here does its job and nothing more. The firmware stores a key. QEMU copies the bytes and tidies up the header. The guest reads the key and activates with it. Not one of them can tell whether the machine underneath is the one the licence was sold with, and none of them was ever meant to.

So the check lands on whoever runs the hypervisor. A licence is an agreement between the person who bought it and Microsoft, and your platform is not a party to it, but it is the thing that moves the key, and that makes the question yours whether you asked for it or not.

Write the answer down before the upload button does anything. One machine, one VM, the customer’s own licence and their word that it covers this. It costs nowt, and it protects you as much as them. The software will move whatever key it is handed. Whether it should have is a question only a person can answer, so make sure one has.