Two topics every growing Proxmox user reaches: handing a real disk or graphics card directly to a VM, and keeping the host itself properly updated. Disk passthrough is easy, GPU passthrough is honestly not, and updates have one specific command discipline that Proxmox expects you to follow. All three, in plain terms.
The first month with Proxmox is VMs and containers. Then the wishes arrive: the NAS VM should own its disk directly, the media server should use the graphics card, and quietly in the background, this host has not been updated since I built it. This page takes all three seriously — with the difficulty labels printed honestly on each.
Passthrough means a VM stops using simulated hardware and takes direct control of a real device. The common home-lab wishes are a disk — giving a NAS VM the physical drive itself so it can read SMART data and manage the disk natively — and a GPU — giving a VM the graphics card for video transcoding or a desktop that must perform. They are very different in difficulty, and honesty requires separating them: disk passthrough is a five-minute job; GPU passthrough is a weekend with good documentation and some luck.
Attach the physical disk to the VM by its stable device ID (never by /dev/sdb, which can change between boots):
Replace 100 with your VM's ID and the ID with your disk's real one from ls /dev/disk/by-id. The VM then sees the bare disk. Two honest warnings: the disk is now exclusively the VM's — the host and other guests cannot use it — and it is not included in Proxmox backups of that VM, because Proxmox does not own its contents. Whatever backup plan that data needs is now the VM's own job.
PCI passthrough of a graphics card requires IOMMU — Intel VT-d or AMD-Vi — present in the CPU and motherboard and enabled in the BIOS and the Proxmox kernel configuration. After that come device IDs, driver blacklisting on the host, and behaviour that varies sharply by GPU generation and vendor; consumer cards range from 'works first try' to famous multi-day puzzles. The use cases that justify it are real (a media server that transcodes on the GPU, a single gaming or CAD VM), but go in with the correct expectation: this is the advanced end of Proxmox, the host loses the use of that GPU for its own console in most configurations, and a spare display output plan for the host is worth having before you start.
Proxmox is Debian underneath, and it is updated like a server, not like a phone. The routine:
apt update followed by apt dist-upgrade.apt upgrade — Proxmox's own guidance, because kernel updates sometimes need new packages that plain upgrade holds back.The rhythm that works for small setups: check for updates every couple of weeks, apply them in a quiet hour, reboot when a kernel lands. A hypervisor that is never updated collects known vulnerabilities; one updated carelessly at noon on a workday collects enemies. The middle path is short, scheduled and boring — exactly what infrastructure should be.
See the full Proxmox installation and first VM creation, live and step by step.
▶️ Watch Full VideoIt needs IOMMU — Intel VT-d or AMD-Vi — supported by both CPU and motherboard and enabled in the BIOS. Most mid-range hardware of the last decade qualifies on paper, but success still varies by GPU model. Check the Proxmox wiki's PCI passthrough documentation for your hardware class before committing a weekend.
Because Proxmox's own documentation says so: kernel and core package updates sometimes require installing new packages or removing old ones, which plain upgrade refuses to do and silently holds back. Following the official pair — apt update, then apt dist-upgrade — keeps the host in the tested state.
For a home or small-office host, a calm fortnightly rhythm is sensible: refresh, review what is offered, back up anything precious, apply, and reboot if a kernel arrived. The exception is a published security fix for something you expose to a network — that one jumps the queue.