Allow destroying only OSDs that belong to the node that has been specified in
the API path.
So if
- OSD 1 belongs to node A and
- OSD 2 belongs to node B
then
- pvesh delete nodes/A/ceph/osd/1 is allowed but
- pvesh delete nodes/A/ceph/osd/2 is not
Destroying an OSD via GUI automatically inserts the correct node
into the API path.
pveceph automatically insert the local node into the API call, too.
Consequently, it can now only destroy local OSDs (fix#2053).
- pveceph osd destroy 1 is allowed on node A but
- pveceph osd destroy 2 is not
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
These 2 files can be helpful for issues with multipath. The multipath -v3
output is too large most of the time and not required for analyzing and
solving the issues.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
The guest iteration is slightly confusing as we also handle the
accumulated pool settings there, so we only check the VM.Audit privs.
for a specific VM and skip to the next if the permissions is not
there after those pool handling.
So, move operations which are only required when VM privs. are there
below this check.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
makes it easier to compare in API responses, and those list are not
huge, seldom over a few thousands, which is peanut crumbs compared to
all the other thing in this perl stack.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
To better match the gauge in the current status infobox in the same
summary panel, which is already using a format where KiB is 1024
the latter needs a (not yet bumped) widget toolkit update to 2.5-2 or
newer, just setting now to avoid forgetting it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Add 'isPBS' parameter for Restore window so we can detect when to show
the 'live-restore' checkbox.
Includes a warning about this feature being experimental for now.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
so it doesn't get out of scope too early.
Regression introduced by 5620e5761e as pointed
out by Fabian Grünbichler.
Reported in the community forum:
https://forum.proxmox.com/threads/limit-simultaneous-backup-jobs.87489
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Otherwise storage_info() cannot be used for (at least) PBS storages from an API
call without 'protected => 1', because the password cannot be read from
'/etc/pve/priv'. Note that the function itself does not need the storage to be
active, because it only uses storage_config() and get_backup_dir().
AFAICT new() is the only existing user of this function and can be responsible
for activating the storage itself.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Now that SLAAC is supported, we can revert commit 793f2cf4.
SLAAC requires cloud-init 19.4 or newer.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
we set the api prefix by default to '/' so we always triggered
the the replacement and added '///' which is wrong and does not
work for the 'health' api path
(influxdb returns 404 for 'https://ip:port///health')
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
the forwards compatible api of 1.8 only contains this path
(not api/v2/health) and it it also contained in the v2 api
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
I normally use a reverse proxy in front of my influxdb instances,
proxying all from the /influx/ path to the only locally listening
influxdb. So here I'd need to set "influx" as api-path-prefix.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Not a hard error, some network box (proxy) down the line could add it
for us, or it could be just not required, so ...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The API doesn't advertise the property as non-optional and it's safer and more
in line with the surrounding code.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
by allowing zero and updating the field name. Otherwise the hint mentioning zero
is wrong. Also, it's not only a read limit as the emptyText already indicates.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The initial value is '' and in getSubmitValue(), previously the branch
if (v == 0 || v == 0.0) return null;
was taken, because of the lax '==' comparision. Make sure we still return null
for '' by explicitly checking for it.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The default is not just "i440fx", this hides the fact that the version
will be pinned to 5.1, unless one deliberately opens the editor.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
We need to detect "isWindows" before splitting a pinned version into
.version/.machine, otherwise .machine will always be "pc" or "q35", and
the check in "isWindows" will succeed even for pinned versions. This
resulted in "5.1" being shown even if a different version has been set
for a Windows machine.
Also alias "pc" directly to "__default__", as they have the same
meaning, but "pc" is not a valid entry in the "machine" combobox,
leading to an invalid state when editing the (valid) configuration of
"machine: pc" on a VM.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
and improve switchting machine type and keeping same version for
the windows based VMs, as we cannot do the same as for other
OS-Types, just select the "latest" magic version.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The initial default from the $confdesc is 1 anyways, and like
this changing the default in /etc/vzdump.conf to 0 actually works.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Hidden behind "Advanced" options, as to not confuse inexperienced users.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
avoid further crowding the top-level node API path with such
"what can some part of the node currently do" stuff, rather move it
down.
The QEMU cpu stuff should move also down there.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as 'machine-types', so it is clear this refers to QEMU machines, not the
local machine (as one might think, this being a 'node' API call).
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this is not something one really questions when not there, so avoid
adding a extra overly specific translation as "No Data" fits quite
well..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
in case a zpool has not been yet scrubbed, there is no 'scan'
information in `zpool status` output.
Adding a informational text in that case might help users to notice
that something is not configured optimally (e.g. disabled cronjob)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
