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>
and guard it to only run on ceph-using systems (the regular 'inited' check
doesn't work as a guard for this, because it checks for new-style inits
including the dir existing).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Due to Ceph dropping privileges when running the 'ceph-crash' daemon
[0], it is necessary to allow the daemon to authenticate with its
cluster in a safe manner.
In order to avoid exposing sensitive keyrings or somehow escalating
its privileges again, 'ceph-crash' is therefore provided with its own
keyring in the '/etc/pve/ceph' directory. This directory, due to being
on 'pmxcfs', may be read by members of the 'www-data' group, which
'ceph-crash' is made part of [1].
Expected Configuration
----------------------
1. A keyring file named '/etc/pve/ceph/ceph.client.crash.keyring'
exists
2. A section named 'client.crash' exists in '/etc/pve/ceph.conf'
3. The 'client.crash' section has a key named 'keyring' which
references the keyring file as '/etc/pve/ceph/$cluster.$name.keyring'
4. The 'client.crash' section has *no* key named 'key'
New Clusters
------------
The keyring file is created and the conf file is updated after the first
monitor has been created (when calling `pveceph mon create`).
Existing Clusters
-----------------
A new helper script creates and configures the 'client.crash' keyring in
`postinst`, if:
* Ceph is installed
* Ceph is initialized ('/etc/pve/ceph.conf' and '/etc/pve/ceph' exist)
* Connection to RADOS is successful
If the above conditions are met, the helper script ensures that the
existing configuration matches the expected configuration mentioned
above.
The configuration is not changed if it is already as expected.
The helper script may be called again manually if the `postinst` hook
fails. It is installed to '/usr/share/pve-manager/helpers/pve-init-ceph-crash'.
Existing `client.crash` Key
---------------------------
If a key named 'client.crash' already exists within the cluster, it is
reused and not regenerated.
[0]: https://github.com/ceph/ceph/pull/48713
[1]: https://git.proxmox.com/?p=ceph.git;a=commitdiff;h=f72c698a55905d93e9a0b7b95674616547deba8a
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
This commit adds the '/etc/pve/ceph' directory to our overall expected
Ceph configuration.
This directory is meant to store cluster-wide, non-private
configuration files used by Ceph applications and services that are
executed with lower privileges, such as 'ceph-crash.service'.
The existence of the directory is now also checked for when checking
whether Ceph is configured correctly. This makes it easier for our
other tooling to rely on the directory's existence, reducing the
number of otherwise needless frequent checking.
* For new clusters: `pveceph init` now creates '/etc/pve/ceph' when
called.
* For existing clusters: The 'postinst' hook this commit adds ensures
that '/etc/pve/ceph' is created when updating.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
Based on how we handle this for PBS but without the hidden fields,
which do not really make this simpler, at least not if the logic is
only required on creation due to the field being only editable then.
As example, if the port of the ESXi host would be 8080, one would
enter `192.168.1.2:8080` for an IPv4 address or `[2001:db8::42]:8443`
for an IPv6 one.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Allows to configure a custom broadcast address to use when sending a
wake on lan packet to wake a remote node.
Default behaviour remains to fallback to 255.255.255.255.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Allows to optionally configure a local interface name to which to
bind to when sending a wake on lan packet to wake a remote node.
Default behaviour remains to send the packet via the interface for
the default gateway.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Moves the wakeonlan property to be a property string, with current mac
address as default key. This allows to later add further optional
properties such as bind-interface and broadcast-address.
Adds the `get_wakeonlan_config` helper function to parse the string
when read from the node config.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
handle mapping purely in the change handler for the prepare-for-virtio
checkbox and avoid any such mapping logic in the renderer, while
slightly longer the code is much easier to reason about.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Otherwise changes will persist, e.g., disabling a CDROM drive won't
work if the values got assembled for the "Resulting Config" tab
before. Same for the "Prepare for VirtIO" checkbox, there one got the
disk twice, once as (old) mapped SATA and once as (original) SCSI.
To fix this do not work on a reference of the original VM config, but
rather always copy that to a new object before applying the form
values.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We switched the storage browser navigation entry to 'Virtual Guests'
recently, but still used the icon for import.
For now switch to use to the one for VMs for this entry, matching the
label, and use the import icon for the "Import" button instead.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Aaron originally designed the new "unique MAC address" checkbox after
this one for alignment reasons [0]. I changed it and argued that's
fine if there is a misalignment between those components [1], which I
still think, but tbh. I also like the boxLabel more for the "Prepare
for VirtIO" checkbox, so lets use it there too and hope all are happy
again.
[0]: https://lists.proxmox.com/pipermail/pve-devel/2024-March/062411.html
[1]: https://lists.proxmox.com/pipermail/pve-devel/2024-March/062412.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Mapping to SATA is only one thing it does, and what we actually want
to do is preparing for VirtIO, the effects are implementation detail,
so name it after the reason not one specific step.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
it's popular in VMware ESXi and so should be available to choose
directly, avoiding a invalid model field in the import wizard.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Avoid some global widget config to store internal state, rather use
the existing viewModel for that.
Also avoid unnecessary references and switch to a boxLabel, drop also
the tooltip, as that doesn't add much here where the effect can be
seen in the grid.
Avoid reconfiguring all grids if only the network one can have changed
due to a change of this check box value.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by adding a new checkbox and render the grid accordingly.
If unique MAC addresses are enabled, set them to undefined when getting
the values from the grid.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
