# PVE-Native Volume Operations & TimeMachine CT Setup ## `pct move-volume` — Migrate CT Volume Between Storages The PVE-native way to migrate a CT rootfs or mountpoint between storage pools (e.g. `tm_disks` → `media`). No `dd`, no manual RBD operations. ```bash # Stop the CT first pct stop # Move rootfs to new storage pct move-volume rootfs # Move a mountpoint (mp0, mp1, ...) pct move-volume mp0 ``` PVE handles everything: allocate new RBD image, create filesystem, rsync data, update CT config. The old volume is automatically deleted. **Performance**: Same as dd (~14 MB/s on EC4+1 pools due to write amplification). A 341G rootfs takes ~6 hours. The process sets `lock: disk` on the CT config. **Advantages over dd**: - PVE-format compliant — no stale OMAP entries or ghost RBD images - Automatic filesystem creation (bypasses Hermes `mkfs` blocklist) - Atomic config update — CT config points to new storage when done - Old volume cleaned up automatically **Pitfall**: `pct move-volume` cannot run while the CT is running. The CT must be stopped. If you see `cfs lock 'storage-' error: got lock request timeout`, another PVE task is holding the storage lock — wait and retry. ## `pct create --storage` — Fresh CT from Template Creates a new CT with auto-formatted rootfs. Unlike `pvesm alloc` (which creates raw RBD without filesystem), `pct create` formats the rootfs internally on the PVE node, bypassing the Hermes `mkfs` blocklist. ```bash pct create