A 4-vCPU Windows Server VM needs 8 core licenses to run under Azure Hybrid Benefit. Not 4. Eight. That one line from Microsoft's docs is where most hybrid-benefit savings quietly leak. Everyone knows AHB makes a Windows VM bill at the Linux compute rate. Far fewer people do the license math per VM instead of per vCPU. Here is the math, on an illustrative fleet I invented (call it ExampleCo, not a real company): - 40 VMs at 4 vCPU - 20 VMs at 8 vCPU - 6 VMs at 16 vCPU Total vCPU: 416. Core licenses needed: 576. The gap is 160 cores, and it comes entirely from the 40 small VMs: 40 x 8 = 320 licenses to cover 160 vCPU. The floor is per VM, so a fleet of small VMs is the most expensive way to hold the same number of cores. What the Microsoft Learn page says (checked 2026-10-26, always confirm against your own agreement and the Product Terms): 1. Minimum 8 core licenses per VM, Standard or Datacenter, with active Software Assurance or a qualifying subscription. 2. A processor license counts as 16 core licenses. 3. Workloads may only run under the benefit during the SA or subscription term. If it lapses, you renew, disable the benefit, or deprovision. Silence is not an option. 4. Standard licenses: on-prem OR Azure, with a one-time 180-day migration overlap. Datacenter VM licensing allows overlap during migration without the 180-day cap. 5. Windows Server AHB is managed per resource. The central scope-level assignment is SQL Server only. Three things worth doing this week: First, inventory. Pull every Windows VM from Azure Resource Graph and look at licenseType. Anything null is paying the full Windows rate. Whether you own the licenses to cover it is the second question, but you can't answer it without the list. Second, count licenses with the floor applied, per VM. Spreadsheets that multiply vCPU by VM count undercount. Third, before you merge small VMs to "fix" the floor, check HA, zone placement, app support and blast radius. Two 4-vCPU VMs becoming one 8-vCPU VM saves 8 licenses in the model and might cost you a resilience story in real life. The license math is an input, not the decision.

Passthrough a GPU to a VM and you've just turned one cluster node back into a pet. That's the part nobody puts in the "run your own LLM on Proxmox" tutorials. Getting the card into the VM takes an afternoon. Living with it is the real job. Here's what actually changes, and I checked each of these against current vendor docs. Passthrough (vSphere DirectPath I/O, Proxmox hostpci): • No live migration. VMware's docs say no vMotion, no suspend, no snapshots for a DirectPath VM. Proxmox's wiki says VMs with passed-through devices can't be migrated, full stop. • vSphere reserves the VM's full memory as soon as you add a PCI device. Your overcommit maths just broke. • Big-VRAM cards need 64-bit MMIO configured (pciPassthru.use64bitMMIO on vSphere, a bigger MMIO window on Proxmox/OVMF). Skip it and you'll be googling "DevicePowerOn failed" at 11pm. • The IOMMU group has to be clean. If your GPU shares a group with a SATA controller, the ACS override is a last resort, not a fix. • NUMA matters. Put the vCPUs on the socket the GPU is physically attached to. vGPU gives you some of the cluster back. vSphere 8 can vMotion vGPU VMs, with stun-time limits and some cluster settings to tune. Proxmox 8.4 added live migration for vGPU mediated devices. Here's what it costs you: • licensing and a license server you now have to keep alive • a supported-GPU list, and no GeForce cards on it • host driver and guest driver versions that have to stay compatible, so every upgrade becomes a choreographed one MIG only exists on specific datacenter cards (A100, A30, H100/H200, Blackwell datacenter parts and some RTX PRO Blackwell). Time-slicing works on more cards but gives you no memory or fault isolation between tenants. How I'd run it: 1. Treat the GPU VM as cattle that just happens to be pinned to one host. Run N+1 GPU hosts, not one. 2. Health-check the inference server and restart the process, not the VM. A wedged GPU sometimes only comes back with a host reboot. 3. Put GPU hosts in their own maintenance window, because DRS won't save you.

Your tagging is fine. Your showback is still going to start a fight. Showback rarely dies on tag coverage. It dies on the remainder: the shared Kubernetes cluster, NAT and egress, the support plan, observability, the platform team, commitment discounts, idle capacity. Somebody has to decide who pays for that, and the formula you pick decides the invoice more than the usage does. ILLUSTRATIVE example. ExampleCo, four teams (Checkout, Search, Data, Platform), one month, total bill 200,000. I ran it through a small Python script so every number below is computed, not vibes. Tag coverage: 92%. Looks great on a dashboard. Directly attributable to the team that consumes it: 60%. The gap is shared pools: the cluster, NAT, observability, support and tooling are all "tagged" to Platform or to nobody. Now allocate the 54,000 of general shared cost three ways. Same bill, three invoices: Checkout: even 58,000 / proportional 62,500 / driver-based 63,300 Data: even 74,000 / proportional 83,000 / driver-based 80,060 Search: even 41,500 / proportional 39,250 / driver-based 38,850 Platform: even 24,500 / proportional 13,250 / driver-based 15,790 Data's invoice moves by 9,000 depending only on a spreadsheet decision. Nobody changed a single resource. Now the part that kills trust. Checkout cuts its direct spend by 30%. The company saves 12,000.00. Under proportional allocation (the usual default), Checkout's invoice drops by 16,000.01, and Data (+2,500.00), Search (+1,250.01) and Platform (+250.00) all get a higher bill for doing nothing. Under driver-based allocation the others absorb +444.45 in total, only because support is still split by spend. Under even split, zero. Proportional is zero-sum and circular. Every saving one team makes is partly invoiced to its neighbours. Do that twice and nobody believes the numbers. Two more traps in the same example: Commitment discounts. The 18,000 commitment fee was bought from the Platform account. "Buyer pays" puts all 18,000 on Platform. Amortized by covered usage it is Checkout 4,500, Search 3,000, Data 10,500, and those teams can actually see their discount.

In July 2026 the EU published the "Digital Omnibus on AI". It pushes the AI Act's stand-alone (Annex III) high-risk obligations from 2 August 2026 to 2 December 2027. Some teams read that as "logging can wait". Wrong lesson. Most infra agents probably aren't Annex III high-risk anyway. But the first time an agent changes something in prod, your security reviewer, your ISO 27001 or SOC 2 auditor, or your own incident review will ask the same questions. Regulation or not. Here's the uncomfortable bit: logs are not an audit trail. Tokens, latency and a stack trace are observability. Audit is being able to prove, after the fact, who did what, as whom, on whose authority, and that nobody edited the record since. The questions you will actually get, per agent action: 1. Who asked for it, and who authorised it? 2. Which identity did it run as? Service account, not "the agent". 3. Which model, which version, which prompt and policy version? 4. What did it see? Inputs and retrieved docs, by reference or hash, not necessarily the content. 5. Which tool calls, with which arguments? 6. What actually changed, on which target? 7. Who approved the human-in-the-loop step, and when? 8. Can you rebuild the whole chain from one correlation ID: gateway, agent, MCP/tool, database? 9. How do you know the record wasn't edited or trimmed? 10. How long do you keep it, and does that clash with your GDPR retention? ILLUSTRATIVE example, invented org: ExampleCo's change-bot scales payments-api from 3 to 6 replicas. Their logs show a 200 from the Kubernetes API and a token count. They can't show that Bob approved it, which prompt version was loaded, or that the agent's own service account couldn't have deleted the log line. That's a vibe, not an audit trail. The traps I keep seeing: Logging full prompts and tool output "for audit", turning your log store into an unmanaged PII copy. Sampling. Fine for traces, fatal for audit. You don't get to sample which deletions you can prove. Logs writable by the same identity the agent runs as.