Redirecting stdout is not a feasible approach, as that also affects
all run_commands and other command executions/forks done by the API
handler, and thus breaks parsing outputs of such command executions
in the API handlers.
We plan to add a `--result-fd` option instead, allowing users to pass
their own file, open FD or named pipe to the pvesh, so that they can
process the output in streaming or in full afterward afterwards.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
otherwise, print/warn statements by the API endpoint are included in the
output, which breaks JSON parsing in case of output-format == json*.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Based to the suggestion of Wolfgang, in regard to `split_list()`,
I converted the `split_list()` to `split(/\0/, $param->{$key});`
this will split the `$param->{$key}` null characters and push each
element to the `$args` array along with the key value.
changes since v1:
* get rid of the `use PVE::Tools qw(split_list);` since not need it anymore.
* replace the split_list to split(/\0/).
Signed-off-by: Moayad Almalat <m.almalat@proxmox.com>
Commit d8cd8e8cf9 introduced a
regression where only stale replicated volumes with an older
timestamp would be cleaned up. This meant that after removing a volume
from the guest config, it would only be cleaned up the second time the
replication ran afterwards. And the volume could become completely
orphaned in case the relevant storage wasn't used by the job anymore.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
while dropping the instance where the local variable was unused.
prepare() was changed a while ago to return all local snapshots.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
when installing non-quincy versions, 'ceph-volume' is not contained in
the respective repositories and, thus, the install process would fail.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
[ T: reworded commit subject ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
storage_check_enabled() already dies with an appropriate error message
so we don't have to handle it here
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
avoid line bloat, use same capitalization style in warnings as (most)
of the rest of code, some style nits
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Adding a flag file during the Ceph installation helps to cover the time
span in which the binary is already present but the installation not yet
done.
The most noticeable effect is that the 'Next' button in the GUI will
only become active once the installation is actually finished and not
earlier.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
The check isn't specific enough, it also catches deb-src entries and
would give a false impression of security in certain circumstances, or
lead to false negatives in case you have a deb-src entry for
buster/updates even though you have bullseye-security in just the next
line -- something that isn't that uncommon for developers.
Signed-off-by: Rhonda D'Vine <rhonda@deb.at>
Reviewed-by: Fabian Ebner <f.ebner@proxmox.com>
If the same local storage is configured twice with content type
separation, migration in PVE 6 would lead to the volumes being
duplicated. As that would happen for every migration, such an issue
would likely be noticed already, and in PVE 7 such configuration is
not problematic for migration anymore. Also, misconfigured
unreferenced volumes are not an issue with respect to the upgrade
itself, just drop the check.
It's not necessary to scan storages with either 'images' or 'rootdir'
anymore, as only the log_info() remains.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Shared storages are not scanned for migration either, so they cannot
be problematic in this context. This could lead to false positives
where it actually is completely unproblematic:
https://forum.proxmox.com/threads/proxmox-ve-7-0-released.92007/post-401165
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
we don't have a mandatory Ceph major version upgrade this time around,
so this check does not make sense. instead, we want noout until the full
cluster is upgraded. let's use the simple approach and just flip the
switch to "turn off noout if all of Ceph is a single version" in the PVE
7.x branch.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
these were mostly relevant for the Luminous -> Nautilus upgrade, and we
don't need to list all the default passing states that our tooling sets
up anyway.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
the old one is not available post-upgrade, let's use a single codepath
for this.
the new API only allows querying user-settable flags, but the only flags
we check besides 'noout' are not relevant for an upgrade of PVE 6.x to
7.x (PVE 6.x only supports Nautilus+ which requires these flags to be
set in order to work) so we can just drop those outdated checks instead
of extending/refactoring the API.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Helpers copied from pve-container to avoid versioned bumps.
Early returns when no containers are running, or the containers don't
use systemd, as well as returning after finding the first affected
container to minimize impact and resource usage.
Checking running containers first since following /proc/<pid>/root is
cheaper than mounting all volumes for a container
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
The nvme-cli package is recommended by (our) Ceph packages, but here
--no-install-recommends is used to avoid pulling in too much.
The issue with not installing nvme-cli is that a "security
information" mail notification is triggered by sudo each time Ceph
tries to get the device health metrics. While there is a sudoers
rule for /usr/sbin/nvme, Ceph uses 'sudo nvme ...', so it does not
apply when the package is not installed.
This didn't seem to happen with sudo in buster.
It's about 1 MiB of additional packages (nvme-cli + uuid-runtime).
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
these were mostly releveant for upgrading from Corosync 2.x to 3.x - so
keep the warnings/errors, but reduce the noise a bit by skipping lots of
PASS output.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
If neither 'rootdir' nor 'images' are configured on a storage, but
there are guest images, just log the number of volumes found. If they
are relevant for migration, the check for unreferenced volumes will
catch them later.
Also detect content type mismatch for all volumes of existing guests,
which also covers the case of a VM image on a storage with only
'rootdir' and vice versa. To catch all such unreferenced volumes too,
it is necessary to scan all storages that do not have both content
types configured.
Change the message from 'will not work' to 'might not work'. If a
volume only referenced by a snapshot is misconfigured, it doesn't mean
that the guest doesn't work at all. Or it might be an ISO on a
misconfigured storage.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
If there is a log_fail, because of misconfigured 'none' content type, the final
log_pass should not be printed.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
