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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Added removal of old kernels and installation of new kernel versions.'update-kernel' checks if the new kernel is installed correctly and displays a message asking to reboot the system.
since the mobile ui shares the Utils code with the desktop web ui, (but
not the proxmox-widget-toolkit) all methods used in constructors, etc.
there must be available in the mobile ui too.
We don't have any notification configuration options in the mobile ui,
and AFAIK we don't plan to add those there, so we can just implement
stub functions. This way the Utils constructor can proceed without
errors, fixing loading the mobile ui.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>
