# PVE Tools Pro: a menu layer over Proxmox VE 9 commands

> PVE Tools Pro is an interactive Bash toolbox for Proxmox VE 9.x hosts that wraps native commands into validated menus. Its value is the confirmation layer and the local mirror path, not any capability the native PVE command line lacks.

**PVE-Tools/PVE-Tools-9** — One-click operations scripts for Proxmox VE 9.x, covering VM lifecycle management, host networking/firewall/IPv6, GPU/PCI passthrough, system maintenance and third-party ecosystem integration.

- Repository: https://github.com/PVE-Tools/PVE-Tools-9
- Website: https://pve.u3u.icu
- Stars: 2,219 · Forks: 254
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/pve-tools-pve-tools-9

## A shell menu wrapped around native Proxmox commands

PVE Tools Pro is an interactive Bash toolbox written for Proxmox VE 9.x hosts, and it states its own position plainly: it does not replace the native PVE commands. What it offers is a set of menu driven flows for the operations an administrator repeats often, each one validating its input before the underlying command runs and each one asking for confirmation when the change is hard to undo. That is the whole value proposition, and it cuts both ways. An operator who already knows the native command line keeps more freedom outside the menus, since a menu can only offer the fields its author thought of. An operator working alone on one machine gets more from the prompts, since the script refuses an inconsistent combination of values before anything reaches the configuration. Feature coverage spans VM and container lifecycle work, host networking, firewall and security groups, IPv6 helpers, GPU and PCI passthrough, source mirror switching and routine system maintenance.

## One pasted line, then the pvetools command

Installation needs Proxmox VE 9.0 or newer and a root shell. The online path is a single line pasted into the PVE terminal, and the launcher downloads the complete program on demand:

```bash
bash <(curl -sSL https://pve.u3u.icu/PVE-Tools.sh)
```

Accepting the default at the prompt starts a quick session that leaves no files on the system, which suits a first look. Choosing option 2 in the menu, or passing `--install`, writes the tool into the system instead. After that three commands exist:

```bash
pvetools              # 启动
pvetools --help       # 帮助
pvetools --uninstall  # 卸载并清理 /opt/pve-tools、日志、备份目录与别名
```

Removal is as explicit as installation, clearing `/opt/pve-tools`, the logs, the backup directories and any aliases created along the way. If curl is missing, `apt update && apt install curl -y` is the documented first step. The repository keeps `PVE-Tools.sh` at the top level next to `src/`, `lib/`, `Modules/`, `Tools/`, `Docs/`, `build.sh`, `dev.sh` and `ci/`, with `VERSION` and `UPDATE` files tracking the build.

## The Chinese mirror path uses a different repository name

Operators who cannot reach the default host are pointed at two separate download routes, one per audience:

```bash
wget https://cnb.cool/PVE-Tools/PVE-Tools-Pro/-/git/raw/main/PVE-Tools.sh
```

```bash
wget https://raw.githubusercontent.com/PVE-Tools/PVE-Tools-9/latest/download/PVE-Tools.sh
```

Both land on a file with the same name, and both are then run the same way:

```bash
chmod +x PVE-Tools.sh && bash PVE-Tools.sh
```

Read the two addresses closely and they do not agree on naming. The repository, the raw URL and the badge at the top of the page all say PVE-Tools-9, while the mainland China route points at a path under PVE-Tools/PVE-Tools-Pro on CNB. The launcher is therefore distributed under a second name in one region, which is worth knowing when comparing checksums or when a tutorial tells you to look for a directory called PVE-Tools-9. The project acknowledges the domestic distribution service in its credits, and the offline route is the only installation path offered, since there is no package manager entry.

## Network and IPv6 changes get a staging step

Host networking is the deepest part of the menu. A configuration wizard builds and removes bridges interactively from vmbr0 upwards, interface address handling covers static IPv4 and IPv6, DHCPv4 and DHCPv6, SLAAC and staged pre-commit entries, and VLAN sub-interfaces are handled alongside bonding in modes 0, 1, 4 and 6. Firewall work is treated as a first class object rather than a set of loose iptables calls, with PVE firewall rules, security groups, and JSON or command line import and export of whole rulesets. IPv6 gets its own assistant that checks readiness and then sets up either bridge passthrough or NAT6 in one step, and a separate diagnostic toolbox bundles traceroute, mtr, nmap and tcpdump. The staged pre-commit mode matters most here, because an address entered on the management interface can cut off the panel that issued the command.

## Passthrough coverage spans four hardware families

The passthrough menus cover Intel integrated graphics through both SR-IOV and GVT-g, direct assignment of the same hardware using a modified QEMU with a ROM download step and boot assistance, NVIDIA cards with driver switching and monitoring plus a guided warning about vGPU, AMD discrete and integrated parts, and generic PCI devices including IOMMU setup, RDM for single disk passthrough, NVMe, disk and controller assignments. That breadth is the argument for installing a script at all, since each of these normally means editing configuration files by hand and getting the ordering of vfio-pci bindings wrong. The cost is that the flow is opinionated: the ROM download and boot helper steps exist for specific Intel hardware, and a reader cannot tell from the documentation which menu entries are safe to skip on a different board. The README does not publish per model support matrices.

## Confirmation prompts, audit logs and pre-operation backups

Risk control is built into the flow rather than added afterwards. High risk actions require a read confirmation followed by a typed confirmation word, key operations are backed up automatically into `/var/backups/pve-tools/`, and every run leaves a timestamped audit log with a rollback guide attached. This is the part of the design with an observable tension. The quick start advertises a quick session that leaves no files on the system, yet the backup directory is described as automatic for key operations. Both can hold only if the quick path skips the backup step as well, which the documentation does not spell out. Anyone who relies on the claim of leaving nothing behind should check that directory by hand after the first risky run. The project's own warning is blunt about the rest: verify a backup and a rollback plan before restore, migration, disk resize, passthrough, network or firewall changes.

## Third party modules inherit the same confirmation gates

Three extension points sit alongside the built-in menus: the FastPVE template market for common VM templates, a Community Scripts collection, and a Modules market where third party function modules can be submitted online and installed. Each of them attaches a risk confirmation flow before it runs. That is a sensible boundary for a host that will run code written by strangers, and the submission path at least gives third party modules one visible front door. It also means the confirmation layer protects against accidental action, not against the content of the module itself, since the prompt is a gate the user passes rather than an inspection of what will execute. The project is explicit that it calls native PVE commands for real and modifies host and VM configuration, and it pushes users to a user agreement page covering scope, risk boundaries and responsibility for network outages, configuration errors and data loss.

## Source switching rewrites state the operator cannot audit

The maintenance menu reaches into system sources: Debian official mirrors and common domestic mirrors, conversion of the PVE enterprise repository to the non subscription one, Ceph mirror sources, container template sources, system updates, the PVE 8 to 9 upgrade path, kernel and subscription management, GRUB backup and restore, and Ceph maintenance. Each of these edits state that an administrator is responsible for, and several of them operate while guests are running. The direct alternative is the native command line plus a configuration management tool, where every change is a reviewed file, and the difference in approach is explicit: this project moves the review into a script's internal logic and a pair of prompts, and the repository offers no per-operation audit trail beyond the timestamped log it writes locally. Confirm that `pvetools --uninstall` clears every directory it created before handing a host back to someone else, since uninstall also removes the logs and backup directories that would otherwise document what happened.

## Conclusion

PVE Tools Pro earns its place on a single host run by one administrator who repeats the same risky operations and wants a confirmation step before each one. It earns nothing on a fleet where scripts and version controlled configuration already cover the ground, because the menus only surface the options the author chose to implement. Before installing on anything with live guests, confirm a verified backup and a maintenance window, then check that curl can reach the bootstrap host, since the default install path fetches a script before anything lands on disk. The last push was on 2026-09-17 and the repository is not archived.

## FAQ

### Does PVE Tools Pro replace the commands built into Proxmox VE?

No. It calls the native PVE commands for real and wraps them in menus that validate input first, so anything the menus do not expose still has to be done the original way.

### What does pvetools --uninstall remove from the host?

It removes /opt/pve-tools together with the logs, the backup directories and the aliases the installer created.

### Can PVE Tools Pro be installed without internet access to the default host?

Yes. Download PVE-Tools.sh from the CNB mirror or the GitHub raw endpoint, then make it executable and run it with bash; this is the documented offline route.

### What is backed up before a risky operation runs?

Key operations are backed up automatically into /var/backups/pve-tools/, and each run leaves a timestamped audit log with rollback guidance.

### How do I clean up leftovers from the older v10 launcher?

If a v10 era bootstrap script or a shadowing alias is detected during installation, the install environment diagnosis entry in menu 8 removes it automatically.

## Sources

- [License: GPL-3.0](https://github.com/PVE-Tools/PVE-Tools-9/blob/main/LICENSE)
- [Project website](https://pve.u3u.icu)
- [PVE-Tools/PVE-Tools-9 on GitHub](https://github.com/PVE-Tools/PVE-Tools-9)
- [README](https://github.com/PVE-Tools/PVE-Tools-9/blob/main/README.md)
- [Releases](https://github.com/PVE-Tools/PVE-Tools-9/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pve-tools-pve-tools-9