we could also add a check somewhere in pve-cluster for this.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
[ TL: squash in changes Fiona proposed for the port syntax/wording ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Commandline/command line/command-line where being used interchangeably,
which is not correct
(see: https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/c/command-line).
use command-line when it is an adjective (e.g. "command-line interface")
and use command line when it is a noun (e.g. "change the setting from
the command line")
Signed-off-by: Noel Ullreich <n.ullreich@proxmox.com>
They are underdocumented and finding information is not that easy.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
[TL: break footnote with long link over multiple lines ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While the '--linkX' paramter works with one dash too, let's use two so
we are in line with the man page and other uses of named parameters.
Since we are at it, prepend the command with '#' as we do throughout
this section.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
sometimes the qdevice setup can fail when copying CA certificates if the
node SSH keys are not matching for some reason.
reported here:
https://forum.proxmox.com/threads/pvecm-qdevice-setup-fails.88681
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With 5 ms (stable!) even mid size cluster can work just fine, and we
know quite some smaller setups that work OK with 6 - 9 ms, so ease
on unnecessarily scaring users into thinking that their network will
cause them trouble.
we got reports of working two node clusters with ~15 ms latency, so
it can work out above 10ms, albeit things start to get really brittle
and def. not something for 3+ nodes.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this adds a warning in the documentation to remove any replication jobs
before deleting a cluster node
Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
Mentions the misleading error message shown, when deleting a node,
because of the failing command:
corosync-cfgtool -k x
Some forum users were confused by this, and believed that the removal of
the node was unsuccessful.
Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
- Remove host name from commands, where it provided no value
- Display new command output for pvecm status
- Shorten command output where unneccessary
- Change migration network example to use CIDR address rather than
address + netmask
Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
although they both act the same, {pve} is more common throughout the
docs, so this helps to keep things more consistent
Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
Move the example into the bulletin points, makes it clearer that they
are connected and avoids interrupting the flow when reading.
Make the whole "important" part a admontion, as such notes should be
self-contained (not split between note and non-note), it also gives
it more visibility.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The output of "pvecm delnode someNode" is "Killing node X". Even though this
only says something about an attempt and not about success, it is not "no
output is returned".
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
The network config examples use the underscore but our tooling
generates the configs with dashes.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
I overlooked the different package names myself. Writing out the two commands
makes this more difficult to overlook.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
We mention Debian as external server before. On Debian it is easily possible
that SSH root login via password is prohibited.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
The official man page fixed this in commit 0a323ff [0] to describe the
actual behaviour: higher knet_link_priority number equals to higher
priority
[0] 0a323ff2ed
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
While yes, there's a note covering this, users have had often
questions about it, or if it's possible at all, so it deserves its
own section, it's more visible and can be better found this way.
Adapt for corosync 3
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Parts about multicast and RRP have been removed entirely. Instead, a new
section 'Corosync Redundancy' has been added explaining the concept of
links and link priorities.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
