IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
both the task and system log API endpoints support downloading the log data.
annotate the API method schema accordingly to allow passing the newly
introduced checks in the API handler that limit download functionality to
annotated endpoints.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
jobs converted from vzdump.cron have an ID of the format
$digest:$counter
where $digest is the hash of the vzdump.cron file, and $counter is the
position of the job within the crontab.
while the section config schema pretends jobs.cfg's section IDs are
of type pve-configid, that is not enforced anywhere, and the API
endpoints managing such jobs allowed arbitrary strings in the past.
the ':' character is not allowed by `pve-configid`, but it is by the
section config parsers and the Job API.
convert the API schema to use the unification of previous definition
used by the job API, and what the section config parser accepts.
Fixes: f5a97f1f5 (api: jobs: vzdump: pass job 'job-id' parameter)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
and put it into PVE::VZDump because there is a cycle between
PVE::Jobs::VZDump, PVE::API2::VZDump and PVE::API2::Backups
that prevents any of those containing it for now.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Previously, the "Add -> TPM State" menu item in the GUI was disabled
if the user did not have Sys.Console privileges. This deviated from
the permission check in the backend, which does not require
Sys.Console but (among others) VM.Config.Disk.
Fix this inconsistency by checking for VM.Config.Disk in the frontend
instead of Sys.Console.
Reported in enterprise support.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
This new endpoint returns node, storage and guest metrics in JSON
format. The endpoint supports history/max-age parameters, allowing
the caller to query the recent metric history as recorded by the
PVE::PullMetric module.
The returned data format is quite simple, being an array of
metric records, including a value, a metric name, an id to identify
the object (e.g. qemu/100, node/foo), a timestamp and a type
('gauge', 'derive', ...). The latter property makes the format
self-describing and aids the metric collector in choosing a
representation for storing the metric data.
[
...
{
"metric": "cpu_avg1",
"value": 0.12,
"timestamp": 170053205,
"id": "node/foo",
"type": "gauge"
},
...
]
Some experiments were made in regards to making the format
more 'efficient', e.g. by grouping based on timestamps/ids, resulting
in a much more nested/complicated data format. While that
certainly reduces the size of the raw JSON response by quite a bit,
after GZIP compression the differences are negligible (the
simple, flat data format as described above compresses by a factor
of 25 for large clusters!). Also, the slightly increased CPU load
of compressing the larger amount of data when e.g. polling once a
minute is so small that it's indistinguishable from noise in relation
to a usual hypervisor workload. Thus the simpler, format was
chosen. One benefit of this format is that it is more or less already
the exact same format as the one Prometheus uses, but in JSON format -
so adding a Prometheus metric scraping endpoint should not be much
work at all.
The API endpoint collects metrics for the whole cluster by calling
the same endpoint for all cluster nodes. To avoid endless request
recursion, the 'local-only' request parameter is provided. If this
parameter is set, the endpoint implementation will only return metrics
for the local node, avoiding a loop.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
[WB: remove unused $start_time leftover from benchmarks]
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This commit adds a new module PVE::PullMetric. This module allows
us to store the status data of various subsystems, including status
data for the most recent pvestatd update loops. Right now, we
store 6 old generations - including the most recent values, that gives
70 seconds of stat history (based on a 10 second pvestatd update loop
interval).
This cache allows us to add support for pull-style metric collection
systems, be it Prometheus/OpenMetrics or some custom, JSON based
metric format.
This patch raises the required lib{proxmox,pve}-perl-rs version
requirements, since we need the new bindings for proxmox-shared-cache.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
[WB: actually bump *runtime* deps in d/control]
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
'suspend' mode should not be shown as `gettext('Snapshot')`
reported in the forum:
https://forum.proxmox.com/threads/152365/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The issue is related to the 'Summary' tab under 'Datacenter' inside a
cluster. To get a steady reading of the storage size data, the
frontend requests the '/api2/json/cluster/resources' every three
seconds to retrieve the necessary data to calculate the used and total
storage size.
The problem occurs when a shared storage is defined and a node goes
offline. As the node is not online, it cannot report the shared
storage size (both used and total) back to the other nodes. The order
of the JSON response is not always the same, so it is possible that
the offline node will appear first. Consequently, the frontend will
display the wrong total and used storage. This is because the shared
storage data has both the maximum disk size and the used disk set to
zero when the node is offline. This causes the total and used space
data to be calculated and displayed incorrectly, leading to
fluctuations in the displayed percentage of used disk space.
To fix this, add a conditional check to skip the storage report if its
status is 'unknown' (regardless of if the storage is local or shared).
This prevents the unreliable data from being processed.
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Igor Thaller <igor.thaller@aon.at>
Not all fields in the VnetEdit dialog are necessary for every zone
type. This lead to confusion for some users. Hide fields in the
VNetEdit dialog depending on which kind of zone is selected in order
to prevent potential confusion.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Theodor Fumics <theodor.fumics@gmx.net>
Reviewed-by: Theodor Fumics <theodor.fumics@gmx.net>
when editing the pci mapping, we set the nodename of the pci/usbselector
to the selected node. At the same time we disable and hide the node
selector, but it still changes it's value to the 'first' node
(alphabetically sorted) and that triggers a change event.
To prevent that we accidentally set the node of the pci/usbselector
too, we need to check here if the field is disabled.
There seems to be a race when loading the nodes for the nodeselector
which leads to inconsistent behaviour, so this was only encountered for
the pciselector, but theoretically it could also happen for the
usbselector so adding that condition to both.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
We need
"utils: add mechanism to add and override translatable notification
event descriptions in the product specific UIs"
otherwise there is an error in the browser console.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
This new API route returns known notification metadata fields and
a list of known possible values. This will be used by the UI to
provide suggestions when adding/modifying match rules.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
This might be useful if somebody wants to match on the new
'backup-job' field in a notification match rule.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
This allows us to access the backup job id in the send_notification
function, where we can set it as metadata for the notification.
The 'job-id' parameter can only be used by 'root@pam' to prevent
abuse. This has the side effect that manually triggered backup jobs
cannot have the 'job-id' parameter at the moment. To mitigate that,
manually triggered backup jobs could be changed so that they
are not performed by a direct API call by the UI, but by requesting
pvescheduler to execute the job in the near future (similar to how
manually triggered replication jobs work).
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
[ TL: fleece in d/control bump for guest-common now that the version
is known ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
By only setting properties that have changed, we can avoid potential
errors in the task.
For example, if one configures the "nosizechange" property on a pool,
to prevent accidental size changes, the task will now only error if
the user is actually trying to change the size.
Prior to this patch, we would always try to set all parameters, even if
they were the same value. In the above example, this would result in the
task ending in error state, as we are not allowed to change the size.
To disable size changing you can run the following command:
ceph osd pool set {pool} nosizechange 1
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
while the ID part was formerly added to the nodename, and thus could
be completely left out, it's now used as full ID, so it must not be
empty as otherwise one gets an error from the API.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Since the ID of an MDS cannot start with a number [0], we cannot just
use the hostname in all situations, as they are allowed to start with
a number.
By having an extra field for the MDS ID, we can check for that via a
regex. This field is filled with the hostname when the host on which
it should be installed is selected.
This means, we can remove the extra ID field, as additional MDS, and
their unique ID can be set with the new ID field.
[0] https://docs.ceph.com/en/latest/man/8/ceph-mds/
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
[ TL: use camelCase for local serviceID variable ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ceph MDS IDs cannot start with a number [0].
[0] https://docs.ceph.com/en/latest/man/8/ceph-mds/
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Currently custom mappings cannot be edited, due to them having no VMID
value. The VMID parameter was always sent by the frontend to the
update call - even if it was empty - leading to validation failure on
the backend. Fix this by only sending the vmid parameter when it is
actually set.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Between the number of CPUs and the actual label, a space was missing -
resulting in an inconsistency vs. the "CPU usage" column.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Comparing with Proxmox.Utils.render_cpu() seems just a slight oversight
in the condition. Fix it by aligning it with how it is done in
Proxmox.Utils.render_cpu() for consistency.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
The `ceph-version` key is not used anymore, so it can go.
Double-checked by `rg`ing through all of our repositories.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Igor Thaller <igor.thaller@brg9.at>
The part of the `get_local_version` sub that's concerned with actually
parsing the Ceph version is factored into a separate sub
`parse_ceph_version`. That way the parsing logic can easily be reused.
Make the version regex more maintainable declaring it as a variable,
breaking it up and commenting it by using the x flag.
Also remove the part that parses our Debian revision (e.g. -pve1) from
the version, as we do not actually include that in our Ceph builds.
The part of the regex that parses the build commit hash is made
mandatory (remove '?' after its group).
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Igor Thaller <igor.thaller@brg9.at>
Currently, the whole mode selector is labeled as experimental, this
does however give the impression that also the default legacy mode is
an experimental mode.
To clarify that only the `data` and `metadata` change detection modes
are experimental, move the experimental label to the individual
modes and explicitly mention the experimental modes in the message.
Also, make it more clear that the archive encoding format depends on
the selected mode.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
The field contains the hostname of the host (without any domain part)
which sends the notification. This field can be used in match-field
match rules.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
- The man page warns about the usage of `hostname -f`, since a host
may have multiple domains (or none at all)
- The fallback PVE::INotify::nodename() already only returned the
hostname without the domain part
- Fencing notifications didn't include the domain part anyway
This may result in soft-breakage for any users who have already relied
on the domain being present. If there is need for it, it could include
a fqdn metadata field.
The hostname property used for rendering the notification template
is unaffected for now.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
This allows users to create notification match rules for specific
replication jobs, if they so desire.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
As recently reported in the community forum [0], 6.8 pve kernels would
not be detected correctly by the script. Allow arbitrary newer
versions if already upgraded for future-proofing.
[0]: https://forum.proxmox.com/threads/145723/post-664612
Suggested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[FG: made `return 0;` explicit in closure]
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
The documentation 'man vzdump' states that the value is in KiB/s. This
is correct, as seen in the plugin implementations, where the value is
multiplied by 1024.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
