1 Proxmox VE Documentation
2 ========================
4 We try to generate high quality documentation for
5 {website}[{pve}], and choose to use
6 http://www.methods.co.nz/asciidoc/[AsciiDoc] as base format.
8 The basic idea is to generate high quality manual pages, and assemble
9 them into a complete book, called link:pve-admin-guide.adoc[Proxmox VE
10 Administration Guide]. So we have one source, and generate several
11 documents from that. It is also possible to generate printable PDF
12 files, or ebook formats ('.epub').
14 When possible, we provide scripts to extract API definitions,
15 configuration or command line options from the source code.
17 To simplify the documentation task, we keep all Documentation within
18 this repository. It is possible to generate the docs without installing
19 any additional Proxmox packages with:
21 make pve-doc-generator.mk
24 To update the auto-generate API definitions use:
28 NOTE: you need a fully installed development environment for that.
34 We generate a development package called 'pve-doc-generator', which is
35 used by other Proxmox VE package to generate manual pages at package
38 Another package called 'pve-docs' is used to publish generated
39 '.html' and '.pdf' files on our web servers. You can generate
40 those Debian packages using:
45 Common Macro definition in link:asciidoc/asciidoc-pve.conf[]
46 ------------------------------------------------------------
48 'asciidoc' allows us to define common macros, which can then be
49 referred to using `{macro}`. We try to use this mechanism to improve
50 consistency. For example, we defined a macro called `pve`, which
51 expands to "Proxmox VE".
53 For URLs which are used more than once, two macros should be defined:
55 * `{name-url}`, which just contains the http(s) URL
56 * `{name}`, which contains the complete link including the canonical
59 For example, the macro `{forum-url}` expands to {forum-url}, and the macro
60 `{forum}` expands to {forum}.
62 The plan is to add more such definitions for terms which are used more
65 WARNING: When asciidoc encounters a misspelled macro name, it will
66 silently drop the containing line!
69 Autogenerated CLI Command Synopsis
70 ----------------------------------
72 We generate the command line synopsis for all manual pages
73 automatically. We can do that, because we have a full declarative
74 definition of the {pve} API. I added those generated files
75 ('*-synopsis.adoc') to the git repository, so that it is possible to
76 build the documentation without having a fully installed {pve}
77 development environment.
82 'asciidoc' uses a fairly simple markup syntax for formatting content.
83 The following basic principles should be followed throughout our
90 Sections are formatted using `two-line titles', by adding a line of
91 the appropriate characters and of the same length as the section title
94 Level 0 (top level): ======================
95 Level 1: ----------------------
96 Level 2: ~~~~~~~~~~~~~~~~~~~~~~
97 Level 3: ^^^^^^^^^^^^^^^^^^^^^^
98 Level 4 (bottom level): ++++++++++++++++++++++
100 NOTE: Level 4 headings are currently not working for `manpage` outputs, you may
101 want to use `.SECTION' instead, which results in the same rendering, and this
102 level of Heading isn't displayed in any Index/TOC anyway.
104 Section titles should always be preceded by two empty lines. Each word
105 in a title should be capitalized except for ``articles, coordinating
106 conjunctions, prepositions, and the word to in infinitives unless they
107 appear as the first or last word of a title'' (see
108 http://web.mit.edu/course/21/21.guide/capitals.htm[Mayfield Electronic Handbook of Technical & Scientific Writing]).
117 Numbered lists should be created using the implicit numbering format:
133 Bulleted lists should be created using the '*' symbol:
146 If you need to have other elements on the same level as a list element you
147 can do this with the '+' symbol:
153 Another Sentence (or Block) on the continued second level.
160 Another Sentence (or Block) on the continued second level.
167 Labeled lists should be used to make lists of key-value style text
168 more readable, such as command line parameters or configuration options:
170 .Regular labeled lists
174 Element text paragraph
178 Another element text paragraph.
183 Element text paragraph
187 Another element text paragraph.
189 .Horizontal labeled lists
192 First Label Text:: Element text paragraph
194 Second Label Text:: Another element text paragraph.
200 First Label Text:: Element text paragraph
202 Second Label Text:: Another element text paragraph.
204 The FAQ section uses a special questions and answers style for
208 Text and Block Styles
209 ~~~~~~~~~~~~~~~~~~~~~
211 'asciidoc' offers a wide range of default text styles:
213 * 'Emphasized text': created using \'text', used for emphasizing words
215 * `Monospaced text`: created using \`text`, used for command / program
216 names, file paths, in-line commands, option names and values
217 * *Strong text*: created using \*text*, used for emphasizing concepts
218 or names when first introduced in a section.
220 There are also different built-in block styles that are used in
223 Complete paragraphs can be included literally by prepending each
224 of their lines with whitespace. Use this for formatting complete
225 commands on their own line, such as:
227 pct set ID -option value
230 By surrounding a paragraph with lines containing at least four '-'
231 characters, its content is formatted as listing.
233 Use this for formatting file contents or command output.
236 Specially highlighted 'tips', 'notes', 'warnings' and 'important' information
237 can be created by starting a paragraph with `TIP`, `NOTE:`, `WARNING:` or
244 WARNING: this is warning
246 IMPORTANT: this is important information
248 For each of these blocks (including lists and paragraphs), a block header
249 can be defined by prepending the block with a `.' character and the header
264 For example, block headers can be used to add file names/paths to file
270 Each {pve} installation contains the full documentation in HTML format,
271 which is then used as the target of various help buttons in the GUI.
273 If after adding a specific entry in the documentation you want to
274 create a help button pointing to that, you need to do the
277 * add a string id in double square brackets before your
278 documentation entry, like `[[qm_general_settings]]`
279 * rebuild the `asciidoc-pve` script and the HTML chapter file containing
281 * add a property `onlineHelp` in the ExtJS panel you want to document,
282 using the above string, like `onlineHelp: qm_general_settings`
283 This panel has to be a child class of PVE.panel.InputPanel
285 On calling `make install` the asciidoc-pve script will populate
286 a JS object associating the string id and a link to the
287 local HTML documentation, and the help button of your input panel
288 will point to this link.
294 [thumbnail="screenshot/gui-datacenter-search.png"]
296 First, it should be noted that we can display screenshots on 'html'
297 and 'wiki' pages, and we can include them in printed documentation. But
298 it is not possible to render them inside manual pages. So screenshot
299 inside manual pages should be optional, i.e. the text should not
300 depend on the visibility of the screenshot. You can include a
301 screenshot by setting the 'thumbnail' attribute on a paragraph:
304 [thumbnail="screenshot/gui-datacenter-search.png"]
305 First, it should be noted ...
308 The corresponding file need to reside inside folder
309 `images/screenshot`, and should be in `.png` image format. We include
310 the screenshots in printed documentation, and 'pdftex' uses the
311 density (DPI) specified inside the file. So all screenshots should use
312 the same density. We currently require the density set to 146 DPI, so
313 that we can display a 1024 pixels wide image. You should not include
314 larger screenshots (although it is possible).
316 You can use the `./png-cleanup.pl` script to set the correct
317 density. Simply use the following command to import a screenshot
321 # ./png-cleanup.pl screenshot.png images/screenshot/screenshot.png
324 TIP: You can use `identify -verbose screenshot.png` command to show
325 all image attributes (from debian package 'imagemagick')
327 .Default Screenshot Layout
329 [thumbnail="screenshot/gui-datacenter-search.png"]
331 We normally display screenshots as small thumbnail on the right side
332 of a paragraph. On printed documentation, we render the full sized
333 graphic just before the paragraph, or between the title and the text
334 if the paragraph has a title. It is usually a good idea to add a title
335 to paragraph with screenshots.
337 [thumbnail="screenshot/gui-datacenter-search.png", float="left"]
339 If you need to render many screenshots, it is possible to place them
340 on the left side, so you can alternate the thumbnail position using the
344 [thumbnail="screenshot/gui-datacenter-search.png", float="left"]
345 If you need to render many screenshots ...
348 Please avoid to many consecutive screenshots to avoid rendering
349 problems. Also verify the printed documentation to see if large
350 screenshots create layout problems.
356 Copyright (C) 2016-2021 Proxmox Server Solutions GmbH
358 Permission is granted to copy, distribute and/or modify this document
359 under the terms of the GNU Free Documentation License, Version 1.3 or
360 any later version published by the Free Software Foundation; with no
361 Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
362 copy of the license is included in the link:LICENSE[LICENSE] file.