PXVIRT brings Proxmox VE tooling to ARM64 and LoongArch
A fork of Proxmox VE for ARM and LoongArch architectures
At a glance
- What is it?
- PXVIRT is an independent fork of Proxmox VE adapted for ARM64 and LoongArch servers, with x86 builds retained for mixed-architecture clusters. It is aimed at administrators who need Proxmox-style virtualization management beyond x86, but installation and release details require checking its external documentation.
- Who is it for?
- PXVIRT is a practical candidate for administrators managing ARM64 or LoongArch hosts, particularly when a mixed-architecture cluster requires x86 and non-x86 nodes. It is a weaker choice for someone expecting official Proxmox alignment, packaged GitHub releases, or self-contained repository installation instructions.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 93 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Why PXVIRT extends Proxmox VE beyond x86
PXVIRT addresses a specific infrastructure problem: Proxmox VE tooling is normally associated with x86 servers, while ARM64 and LoongArch hosts use different processor architectures. The project adapts the Proxmox VE software stack for those systems so administrators can use similar virtualization management capabilities on non-x86 hardware. The README identifies PXVIRT as a fully independent fork, although its inherited features and code remain closely tied to Proxmox VE.
The intended users are infrastructure administrators, homelab operators and organizations running ARM64 or LoongArch servers. PXVIRT also supplies x86 versions, according to the README, allowing x86, ARM64 and LoongArch systems to participate in one cluster. That mixed-architecture support is a more precise reason to consider the fork than generic ARM compatibility: the goal is to preserve a common management model while removing the architecture restriction.
The project originally operated under the name Proxmox-Port. It was renamed after Proxmox was identified in the README as a registered trademark of Proxmox Server Solutions GmbH. PXVIRT also states that it is not affiliated with Proxmox Server Solutions GmbH and is intended to expand access rather than replace Proxmox VE. Users of the old project should migrate because the README explicitly marks Proxmox-Port as deprecated and says it will no longer receive updates.
The inherited KVM, container and cluster stack
PXVIRT does not describe a newly designed hypervisor from first principles. Its feature set is inherited from Proxmox VE and extended for ARM64 and LoongArch. The documented stack includes KVM virtualization, containers, a web-based management interface, storage integration and network configuration tools. In practical terms, the project aims to retain the familiar Proxmox management layer while rebuilding or adapting the underlying packages for additional processor families.
The README also states that the fork maintains compatibility with Proxmox VE upstream features. It describes this as upstream synchronization rather than documenting a fixed release cadence or a list of synchronized versions. The repository has no GitHub releases, so there is no release entry here that identifies a stable package set, upgrade notes or supported Proxmox VE baseline. Upstream compatibility should therefore be treated as a project goal, not proof that every deployment runs identical versions across all architectures.
Cluster design is the central architecture-specific feature described by the project. Including x86 builds alongside ARM64 and LoongArch builds allows administrators to address a cluster through the same product family. The README does not document which CPU models, accelerators, kernel configurations, machines or devices are supported on each architecture. It also does not explain live migration behavior between unlike processor architectures, guest feature parity or cluster upgrade sequencing. Those are adoption constraints that must come from the hardware and release documentation.
Installing PXVIRT through the external documentation
The README does not provide installation commands, a package repository URL, an ISO download location, supported hardware list or a first-boot procedure. It sends installers to the separate PXVIRT documentation site:
https://docs.pxvirt.lierfang.com
The site has English and Chinese documentation links, but its content is not reproduced in the repository README. A reader should follow the documentation for the relevant architecture and verify whether it requires an ISO, repository packages, a particular image or other preparation.
The repository contains `build.sh` and directories named `packages` and `docker`, but the README does not explain their intended workflows. Their presence does not establish a supported build path for end users. In particular, readers should not assume that cloning the repository and running `build.sh` is the documented installation method. The first real use also cannot be reduced to a confirmed command sequence because PXVIRT does not publish one in the README.
Repository activity and upgrade boundaries
The repository is not archived, and its last push was on 2026-07-22. That is recent enough to show repository activity, but it does not reveal the contents of the change, whether a release was produced or whether a particular hardware target passed a documented test matrix. The repository also has no GitHub releases, leaving users without release-tagged upgrade notes in that location.
This distinction matters because a fork can receive source changes without supplying a complete migration artifact. An administrator may need to establish which PXVIRT packages are deployed on each node, how those packages relate to Proxmox VE packages, and what order must be used for an upgrade. The README does not document rollback, mixed-version operation, database migration or support boundaries. It also does not promise that support includes production clusters.
The roadmap lists Easy DPDK, Datacenter Manager, IPMI, StorCLI, automatic diagnosis, SAN management, SR-IOV management and VIP as future work. These names describe intended additions, not confirmed shipped capabilities. Operational planning should not budget a deployment around roadmap items without checking the current documentation and build artifacts.
AGPL-3.0 and the independent-fork boundary
PXVIRT is distributed under AGPL-3.0, and the README says the original Proxmox VE code is also covered by AGPLv3. For engineers, the source-license obligations of the inherited code remain relevant after rebranding and porting. This review does not interpret the license or provide legal advice. It only records the stated licensing boundary.
The trademark issue is separate from the open-source license. The project changed its name because the README says Proxmox is a registered trademark, and it expressly disclaims affiliation with Proxmox Server Solutions GmbH. The repository name, product name and upstream ancestry should not be treated as evidence that PXVIRT is an official Proxmox distribution.
The README encourages considering support for both projects where appropriate. That is a small but important compatibility choice: PXVIRT seeks broader architecture access, while upstream Proxmox VE remains a separate project. Buyers and operators should verify package provenance, support channels and upgrade procedures before combining software from both ecosystems.
Where PXVIRT differs from native Proxmox VE deployments
The real alternative is native Proxmox VE on its documented hardware targets. Its approach starts from the upstream product directly, whereas PXVIRT modifies or packages that software for ARM64 and LoongArch. For an x86-only deployment, native Proxmox VE avoids the compatibility work and release-tracking questions created by a downstream fork.
PXVIRT is the more relevant option when the host processor is ARM64 or LoongArch and the administration team wants the Proxmox model rather than choosing a different virtualization platform. Its x86 builds can keep those non-x86 nodes within a cluster managed through the same software family. The trade-off is dependence on a separate community project and an external documentation site, especially while the repository publishes no GitHub releases.
The fork is a poor fit for an operator whose primary requirement is official Proxmox affiliation, a documented x86 release train or support entirely from the repository itself. The README also leaves important architecture limits unstated. Hardware compatibility and upgrade behavior must be checked before an existing production environment is migrated.
Editorial conclusion
PXVIRT is a practical candidate for administrators managing ARM64 or LoongArch hosts, particularly when a mixed-architecture cluster requires x86 and non-x86 nodes. It is a weaker choice for someone expecting official Proxmox alignment, packaged GitHub releases, or self-contained repository installation instructions. Verify the external documentation first, then confirm the target hardware, current package sources, upstream synchronization state and migration path from any existing Proxmox-Port deployment.
Frequently asked questions
What is PXVIRT used for?
PXVIRT adapts Proxmox VE tooling for ARM64 and LoongArch servers. It provides a web interface, KVM, containers, storage management and network configuration for those architectures.
Does PXVIRT replace Proxmox-Port?
Yes. The README marks Proxmox-Port as deprecated, says it will no longer receive updates and directs future development to PXVIRT.
How do I install PXVIRT?
The README directs users to https://docs.pxvirt.lierfang.com. It does not contain install commands, ISO locations or package repository instructions.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/jiangcuo-pxvirt)Was this useful?