Implement a new "guest stop" confirmation message box which first
checks if there is an active shutdown task for the same guest that is
visible to the logged-in user. If there is at least one, the dialog
displays an additional default-on checkbox for overruling active
shutdown tasks. If the user confirms and the checkbox is checked, the
UI sends a guest stop API request with the `overrule-shutdown`
parameter set to 1. If there are no active shutdown tasks, or the
checkbox is unchecked, the UI sends a guest stop API request without
`overrule-shutdown`.
To avoid an additional API request for querying active shutdown tasks,
check the UI's current view of cluster tasks instead, which is fetched
from the `pve-cluster-tasks` store.
As the UI might hold an outdated task list, there are some
opportunities for races, e.g., the UI may miss a new shutdown task or
consider a shutdown task active even though it has already terminated.
These races either result in a surviving shutdown task that the user
still needs to abort manually, or a superfluous `override-shutdown=1`
parameter that does not actually abort any tasks. Since "stop
overrules shutdown" is merely a convenience feature, both outcomes
seem bearable.
The confirmation message box is now always marked as dangerous (with a
warning sign icon), whereas previously it was only marked dangerous if
the stop issued from the guest panel, but not when issued from the
resource tree command menu.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: squash in some slightly opinionated code/style clean-ups ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
There's a new firewall implementation available as `proxmox-firewall`
package, in contrast to the existing `pve-firewall` package it is
using nftables directly, not the legacy iptables, and can thus
leverage a modern stack with atomic updates, avoiding the need for
different tools (e.g., ebtables), and not requiring intermediate
firewall bridges to handle VM flow correctly. Additionally it's
written in rust, making it more efficient and safer to change.
The new implementation is using the same configuration file as source
and should be mostly the same in semantic behavior, it basically is a
drop-in replacement besides one known issue:
There is currently one major issue that we still need to solve:
REJECTing packets from the guest firewalls is currently not possible
for incoming traffic (it will instead be dropped).
This is due to the fact that we are using the postrouting hook of
nftables in a table with type bridge for incoming traffic. In the
bridge table in the postrouting hook we cannot tell whether the packet
has also been sent to other ports in the bridge (e.g. when a MAC has
not yet been learned and the packet then gets flooded to all bridge
ports). If we would then REJECT a packet in the postrouting hook this
can lead to a bug where the firewall rules for one guest REJECT a
packet and send a response (RST for TCP, ICMP port/host-unreachable
otherwise).
While this is being addressed, and the whole stack is better tested in
general, the new FW will be only enabled if the admin enables a
boolean configuration which this patch exposes on the UI.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
to make the backup fleecing feature available. The bump for
qemu-server is also required for moving unused disks of VMs.
The bump for libpve-common-perl is required because of pve-common
commit c302a28 ("json schema: add format description for
pve-storage-id standard option"), which is required for API
verification.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Similar to how Datastore.AllocateSpace is required for the backup
storage, it should also be required for the fleecing storage.
Removing a fleecing storage from a job does not require more
permissions than for modifying the job.
Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Previously, the result would only be returned implicitly and if not
already parsed. While callers do not strictly need the return value,
future callers might mistakenly rely on it and even work by chance in
some scenarios, because of the implicit return. Make the code more
future proof by explicitly returning the result in all cases.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
with their details as well as pinned packages. Omit the "origin"
lines, as their value is already visible in the URLs.
# apt-cache policy ...
Package files:
100 /var/lib/dpkg/status
release a=now
500 https://enterprise.proxmox.com/debian/pve bookworm/pve-enterprise amd64 Packages
release o=Proxmox,a=stable,n=bookworm,l=Proxmox VE Enterprise Debian Repository,c=pve-enterprise,b=amd64
...
Pinned packages:
intel-microcode -> 3.20231114.1~deb12u1 with priority 1234
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
to recognize temporal correlations with network/load/backup/etc issues
Suggested-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
to get a first clue for debugging passthrough and similar issues, when
no dmesg output has been provided yet.
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
Makes it consistent with the user selector and token selector.
Requested in the community forum:
https://forum.proxmox.com/threads/144978/
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
This reverts commit 3a259c22e6.
There was an oversight with recent replication fixes that led to
attempting to remove snapshots that do not exist (in more scenarios).
While not an issue with real consequences, it's confusing to users.
This has since been fixed by pve-guest-common commit "replication:
snapshot cleanup: only attempt to remove snapshots that exist".
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Adds fields for eab credentials. By default eab is optional, but if the
directory should report that eab is required, the eab credential fields
are marked as mandatory and prevent the form from being submittable
until credentials are provided.
Signed-off-by: Folke Gleumes <f.gleumes@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch allows the user to set a custom ACME directory by providing
a 'Custom' option in the directory dropdown. This in turn reveals an
input for the url. When using a custom directory the directory has to
be manually queried via button press to prevent from spamming the
directory on every input.
Signed-off-by: Folke Gleumes <f.gleumes@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
else this can break an upgrade for unrelated reasons (regular debhelper also
constructs the restart invocations like this, it even redirects output to
/dev/null)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
it looks a bit tall and cramped nowadays, so go for 720, like the
wizard class uses by default.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
that could make some users (not reading the explanation on the right
closely) belief that this controls the amount of parallel VMs to be
backed up or the like.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Also need to check for enable/disable of the compression selector,
because with PBS the value zstd is set, but the thread count setting
doesn't apply.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
pigz is not exposed, because it only works after manually installing
the pigz package.
ionice is not exposed, because it only works in combination with the
BFQ scheduler and even then not in all cases (only affects the
compressor when doing snapshot/suspend mode backup of a VM).
The pbs-entries-max performance option is not exposed. It is rather
niche and hard to understand. It serves as an escape hatch for
rare/extreme cases.
These can still be added with appropriate notes if there is enough
user demand.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently, fallback for the 'performance' option is done as a whole,
taking away flexibility from the user. It also means that when only
one of the two sub-properties is specified, the other one will default
to the backend (i.e. QEMU or proxmox-backup-client) default rather
than the schema default. For the latter point in particular, it can be
argued to be incorrect. These limitations will only get worse in the
future with more sub-properties.
Switch to a per-property fallback mechanism to improve the situation,
having each go through the usual preference order (CLI/job > node-wide
default > schema default).
Technically, this is a breaking change, but pbs-entries-max is rather
new and potential for breakage seems rather low. Requirements for
breakage:
* job (or CLI) that defines only one of the performance options
* job also covers a guest where the other performance option applies
* the other performance option is defined in the node-wide configuration
* the node-wide setting is worse for the job than the implicit backend
default (because this change will have the node-wide default win over
the implicit backend default).
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The 'performance' option itself defines no 'default' in the schema, so
what happened is that the defaults used by the backends (i.e. QEMU and
proxmox-backup-client) would be used. Luckily, they correspond to the
default values defined in the schema, i.e. in the 'backup-performance'
format. Make the code future-proof and use the actual defaults defined
in the schema instead of relying on that correspondence.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
try to make it more clear that the file UID/GID/mode are for the
device file node inside the CT
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this is not like mount points, where the order can make a difference,
but rather like the PCI passthrough for VMs, for which we do not
expose editing the ID either.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With the current implementation using queryDelay, this means that the
change event for the input never completes. This in turn leads to
the input panel never changing its dirty status. By using the
beforequery event we can simply cancel the query without resorting to
the queryDelay hack.
Reported-By: Mira Limbeck <m.limbeck@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Mira Limbeck <m.limbeck@proxmox.com>
Reviewed-by: Mira Limbeck <m.limbeck@proxmox.com>
fall back to using v.ref as value when we do not have an alias or ipset
since scope and name are not set for ips / cidrs
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Filip Schauer <f.schauer@proxmox.com>
Reviewed-by: Mira Limbeck <m.limbeck@proxmox.com>
Tested-by: Mira Limbeck <m.limbeck@proxmox.com>
