Please coordinate your efforts with us before starting any development. It is important to have a common view of the problem and the corresponding solution – just to avoid duplicated or unnecessary efforts.
We will only include software which matches our quality criteria. The source code repository is read only. To include some code, send it as patch (git diff) to the pve-devel mailing list. We will review your code and commit after a successful review (and possible corrections/additions).
This is the primary communication channel for developers, discussing new features and implementation details. If you are a developer and you want to develop additional features, this is the place to start.
PVE Development List: https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Access to Code Repository (git)
You could find build instructions here :
Development Package Repository
Some packages required for development can only be found in the devel repository. This is a cross project repository and may be used for all Proxmox Projects.
Add the following to the
For Proxmox VE 8.x based on Debian 12 Bookworm
deb http://download.proxmox.com/debian/devel/ bookworm main
For Proxmox VE 7.x based on Debian 11 Bullseye
deb http://download.proxmox.com/debian/devel/ bullseye main
For Proxmox VE 6.x based on Debian 10 Buster
deb http://download.proxmox.com/debian/devel/ buster main
Checking out a git repository
To clone a repository run 'git clone' with the repository name prefixed with the common URL: git://git.proxmox.com/git/
# git clone git://git.proxmox.com/git/pve-manager.git
To update an already cloned project to the current version use:
# git pull
Working on the code
For Perl, we recommend having a look at our perl style guide.
For our Rust code we use
rustfmt (e.g., through
cargo fmt) with default settings.
Compiler warnings must be avoided.
Additionally, one might check lints reported by
cargo clippy, but we do not accept mass fixing of those all over the place, such fixes are not always productive and can introduce actual subtle (logical) errors.
eslint as separate package to check basic code standards. New contribution must not ensure that eslint doesn't output any warning or error.
We use the ExtJS framework for the web UI Components, its API documentation can be found at https://docs.sencha.com/extjs/7.0.0/.
Avoid overly long line. Use line-length from context, which is 80 character columns most of the time, try to stay below 100 as maximum.
Adhere to our Technical Writing Style Guide.
If you are not familiar with git it could be worth to take a look at this interactive tutorial: https://try.github.io and read a brief introduction chapter from the official git documentation: https://git-scm.com/docs/gittutorial to gain basic knowledge on it.
First, configure your real name and email address for git, if not done already:
$ git config --global user.name "John Doe" $ git config --global user.email firstname.lastname@example.org
This will be used to sign off commits as your work.
It is recommended to start a feature branch before working on the code locally:
# git checkout -f -b my_branch master
After this you can start working on your improvements. You'll be able to compare your changes to the current PVE master branch easily with
# git diff master..my_branch
Commits and Commit Messages
Then, make your commit (try to make small, but self-contained, commits) and include a sign-off line (-s).
- Make sure the line-length (text-width, column count) of the commit's message is not longer than 70 characters.
- Note, HTTPS links and git trailers (e.g.,
Fixes:) are an exception and should not be split.
- If it fixes a bug start with that information in this form:
fix #1234: summary here
- If it implements a feature tracked on Bugzilla you can also use:
close #1234: summary herealbeit
fix #1234:is more commonly used and also fine
- Try to add a tag denoting the subsystem at start, if an obvious choice exists.
- For example, if you changed the QEMU UI component in pve-manager, a possible tag could be
ui: qemu: summary here
- Don't add tags for things that are already clear from context, for example, adding a
qemutag for a patch in the qemu-server repository has no use.
- But, do not just paste the affected files, including (parts of the) path and maybe even the file ending, as tag! That has no use (already contained in diff stat) and just makes it harder to read.
- For example, if you changed the QEMU UI component in pve-manager, a possible tag could be
You can always edit the commit message of the most recent commit using amend:
# git commit --amend
If you work on a series you can use rebase to re-order, drop, squash/fixup and edit both the whole commit or just rewording its message:
git rebase -i --autosquash --autostash origin/master
autostash is not required, but convenient if there are still pending changes, it will stash before rebase starts and apply again after rebase is done.
autosquash is also not required, but very convenient to auto squash fixups (
git commit --fixup=<ref>) made for older commits in a development series
The following command will take all changes of tracked files and add it to the commit:
# git commit -s -a
New files won't get added automatically. To do that, or to just add some changed files to a commit, use
# git add newfile1.pl file2.pl
You can always look at what will get into commit with:
# git diff --staged
|Note: Note that we need a valid CLA to include your changes|
Since we have several projects in our git repository and only one development mailing list, we ask you to clarify which repository your patches are meant for by specifying it in the subject prefix. Since some names are long it's fine if you shorten them (eg. remove the 'pve-' prefix).
Creating the raw patch series, for instance for the pve-container package:
# rm -rf my-patches/ # to clean left-overs # git format-patch -o my-patches/ --subject-prefix="PATCH container" master..my_branch --cover-letter
Explain in the cover letter the aim of your patches:
# git send-email --email@example.com my-patches/00*.patch # rm -rf my-patches/ # to clean left-overs
If you wish to write comments for individual patches, you can do that either in the cover-letter, or in the patch's commit summary section (between the line consisting of 3 consecutive dashes ending your commit message and before the list of files with their change-counts.
From 12345abcde Mon Sep 12 00:00:00 2001 From: Git Committer <some email address> Date: Fri, 7 Oct 2016 08:30:17 +0200 Subject: [PATCH v2 container 1/2] Fix #1013: this and that Here is your commit message. It explains the bugfix and ends after this line. Signed-off-by: Firstname Lastname <firstname.lastname@example.org> --- ***HERE*** you can write your comments. If this is a new version of an old patch, explain your changes here, for example: changes since v1: * fixed an error in the new regex * reworked algorithm to be O(n) src/PVE/Tools.pm | 2 +- diff --git a/src/PVE/Tools.pm b/src/PVE/Tools.pm (...)
If you want to send several related patches for one feature but different repositories, you can first iterate over all involved repositories, save the patches into one directory and then do a single git send-email over all generated patches. For example, lets go to a few repos and format the most recent commit as patch to /tmp/patchq, then send it:
# cd pve-manager; git format-patch -s -o /tmp/patchq -1 # cd ../pve-guest-common; git format-patch -s -o /tmp/patchq -1 # cd ../pve-docs; git format-patch -s -o /tmp/patchq -1 # git send-email --compose --email@example.com /tmp/patchq/*
Using "start-number" and the like can improve this further, but it's a good start.
If an updated version of your patch series is called for, it should be sent as a new series rather than as reply to the old series. Always send the whole series with all patches showing the same version. Please mark your versions in your subject prefix with a small 'v' followed by the version number like this:
# git format-patch -o my-patches/ --subject-prefix="PATCH v2 container" master..my_branch
Please list all the changes to the previous versions in the commit summary section as shown in the above example.
For patches with no changes to the previous version, you should mention that there were no
changes in the summary section, like
no changes since last version
If your series has a cover letter, also summarize all changes in it as well.
After reviewing patches which affect a subsystem you maintain, you can notify committers that you reviewed the patch and are OK with the changes by using:
Acked-by: Full Name <email address>
For convenience, you can store the pve-devel email address and the repository's default subject prefixes in your repository clones' configurations as follows:
$ git config --local sendemail.to firstname.lastname@example.org $ git config --local format.subjectprefix 'PATCH container' $ git config --local format.signoff true
Now the commands to create and send patches become:
# git format-patch -o my-patches/ master..my_branch # git send-email --compose my-patches/00*.patch
git send-email to send out patches, otherwise the indentation and formatting will get mangled, and the patch cannot be applied anymore.
See https://git-send-email.io/ for an interactive tutorial to setup
Using Authenticated SMTP Server
git send-email can be instructed to use a specific SMTP server for sending, the following shows an anonymized config section example:
[sendemail] smtpencryption=tls smtpserver=webmail.example.com smtpserverport=587 email@example.com smtpsslcertpath= confirm = always
Add this to your global user
~/.gitconfig or to the per project
git send-email will then use these settings by default and ask you for the password on sending.
To send the last two commits for a Proxmox VE project to the Proxmox VE development list you could then execute:
git send-email --to="firstname.lastname@example.org" -2
If you're not used to
git send-email it can be a good test to first send the patches to an email address of yourself, that allows to ensure all details and commands are correct.
Software License and Copyright
We only include code licensed under the respective repo's license, visible under
debian/copyright. For most of our projects, or if in doubt, this is the GNU Affero General Public License, version 3 http://www.gnu.org/licenses/agpl-3.0.html.
Additionally, we require that contributors send us a contributor license agreement form by email to
This agreement establishes a relationship between us and the contributor, gives details on what it means when the contributor grants permission for their work to be included in a project, and enables us to be better stewards of these projects.
With the contributor agreement chosen by Proxmox, the Harmony CLA, the contributor gives Proxmox a license to use their contributions. The contributor continues to own the copyright in the contribution, with full rights to re-use, re-distribute, and continue modifying the contributed code, allowing them to also share that contribution with other projects.
We've tried to keep the agreement as simple and comprehensible as possible. It comes in two flavors:
- one for individual contributors
- and one for entities contributors (companies, foundations, or other organizations).
If you are making a contribution that is not your work (for example, a patch or library written by someone else), please contact email@example.com for guidance on whether any additional steps are needed.