Am 05.11.24 um 12:08 schrieb Aaron Lauterer:
> The same storage needs to be configured on the target node for the
> replication to work.
>
> Signed-off-by: Aaron Lauterer
> ---
> pvesr.adoc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/pvesr.adoc b/pvesr.adoc
> index
Am 05.11.24 um 12:08 schrieb Aaron Lauterer:
> Signed-off-by: Aaron Lauterer
> ---
> pvesr.adoc | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/pvesr.adoc b/pvesr.adoc
> index 4fc2de1..209f306 100644
> --- a/pvesr.adoc
> +++ b/pvesr.adoc
> @@ -181,6 +181,12 @@ A replication job is
superseded-by version 2:
https://lore.proxmox.com/pve-devel/20241129150013.323432-1-c.eb...@proxmox.com/T/
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Allow to select the change detection mode when performing manual
backups of containers with Proxmox Backup Server as target, just like
for the advanced backup job options introduced by commit 3b21f19f
("www: advanced backup: add pbs change detection mode selector").
The selector is shown for virtu
Am 31.05.24 um 12:07 schrieb Fiona Ebner:
> As reported in the community forum [0], for tar, an exclusion pattern
> with a trailing slash will not match a folder with that name. For
> rsync and proxmox-backup-client however, such a pattern will exclude
> a directory with that name, but not a file.
Am 09.09.24 um 12:20 schrieb Fiona Ebner:
> Many people will use 'upgrade' instead of 'full-upgrade' or
> 'dist-upgrade' (e.g. [0][1]) despite the documentation explicitly
> mentioning 'dist-upgrade' [3]. Proxmox projects use different
> packaging guarantees than Debian (necessary for a rolling rel
Am 23.07.24 um 17:25 schrieb Fiona Ebner:
> Since there are certain checks that depend on the QEMU binary version,
> tests with a fixed QEMU binary version make it less likely to catch
> issues on current setups, because current setups will always have a
> newer QEMU binary version than the test.
>
Am 16.09.24 um 18:38 schrieb Daniel Kral:
> Improves checks if the underlying storage, where VMs are restored to,
> support the content type 'images'. This has been already the case for
> backup restores, but is refactored to use `check_storage_alloc` and
> `check_volume_alloc`.
>
> Adds a check r
Am 16.09.24 um 18:38 schrieb Daniel Kral:
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index a0abe44f..13c1c4e0 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -220,18 +220,6 @@ my $check_storage_access_clone = sub {
> return $sharedvm;
> };
>
> -my $check_storage_acces
Am 16.09.24 um 18:38 schrieb Daniel Kral:
> @@ -68,7 +72,7 @@ my $base_env = {
> content => {
> images => 1,
> }
> - }
> + },
Nit: unrelated hunk should be it's own patch
> }
> },
> vmid => 8006,
For issues like these, it's often nice to start out with the fix and put
bigger refactorings later. Then the fix can already be applied up-front
while discussing the bigger changes.
Am 16.09.24 um 18:38 schrieb Daniel Kral:
> diff --git a/PVE/QemuServer/Helpers.pm b/PVE/QemuServer/Helpers.pm
> ind
Am 16.09.24 um 18:38 schrieb Daniel Kral:
> @@ -197,6 +198,25 @@ sub check_volume_alloc : prototype($$;$) {
> return 1;
> }
>
> +=head3 alloc_volume_disk($storecfg, $storeid, $vmid, $format, $name,
> $size_kb)
> +
> +Allocates a volume disk image on C<$storeid>, that is defined in
> C<$st
Am 16.09.24 um 18:38 schrieb Daniel Kral:
> diff --git a/PVE/QemuServer/Helpers.pm b/PVE/QemuServer/Helpers.pm
> index 0afb6317..9d0f24aa 100644
> --- a/PVE/QemuServer/Helpers.pm
> +++ b/PVE/QemuServer/Helpers.pm
> @@ -106,6 +106,51 @@ sub vm_running_locally {
> return;
> }
>
> +=head3 chec
On 11/29/24 14:25, Shannon Sterz wrote:
On Fri Nov 29, 2024 at 2:18 PM CET, Christian Ebner wrote:
On 11/29/24 14:09, Shannon Sterz wrote:
On Fri Nov 29, 2024 at 1:40 PM CET, Christian Ebner wrote:
Allow to select the change detection mode when performing manual
backups of containers with Prox
On Fri Nov 29, 2024 at 2:18 PM CET, Christian Ebner wrote:
> On 11/29/24 14:09, Shannon Sterz wrote:
> > On Fri Nov 29, 2024 at 1:40 PM CET, Christian Ebner wrote:
> >> Allow to select the change detection mode when performing manual
> >> backups of containers with Proxmox Backup Server as target,
On Fri, Nov 29, 2024 at 02:18:25PM +0100, Shannon Sterz wrote:
> On Fri Nov 29, 2024 at 2:08 PM CET, Christoph Heiss wrote:
> > [..]
> > @@ -27,14 +27,13 @@ Mailing Lists
> > This is a fast way to communicate with the {pve} community via email.
> >
> > * Mailing list for users:
> > - http://list
On Fri Nov 29, 2024 at 2:08 PM CET, Christoph Heiss wrote:
> It's been the preferred mailing list archive for some time now.
>
> Signed-off-by: Christoph Heiss
> ---
> getting-help.adoc | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/getting-help.adoc b/getting-help.
On 11/29/24 14:09, Shannon Sterz wrote:
On Fri Nov 29, 2024 at 1:40 PM CET, Christian Ebner wrote:
Allow to select the change detection mode when performing manual
backups of containers with Proxmox Backup Server as target, just like
for the advanced backup job options introduced by commit 3b21f
On Fri Nov 29, 2024 at 1:40 PM CET, Christian Ebner wrote:
> Allow to select the change detection mode when performing manual
> backups of containers with Proxmox Backup Server as target, just like
> for the advanced backup job options introduced by commit 3b21f19f
> ("www: advanced backup: add pbs
It's been the preferred mailing list archive for some time now.
Signed-off-by: Christoph Heiss
---
getting-help.adoc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/getting-help.adoc b/getting-help.adoc
index 06a25c2..e53592d 100644
--- a/getting-help.adoc
+++ b/getting-
Allow to select the change detection mode when performing manual
backups of containers with Proxmox Backup Server as target, just like
for the advanced backup job options introduced by commit 3b21f19f
("www: advanced backup: add pbs change detection mode selector").
The selector is only shown in t
.. in accordance with current NIST recommendations [0].
It's 2024; so reasonable to expect an 8-character-password at the
minimum.
[0] https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* rebased on latest master
* adapted html te
Extends our "test runner" for the parse-answer tests such that if a test
file ends with ".fail.toml", it is considered a negative test and
expected to fail. The expected error message is stored in the
accompanying .fail.json file.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* new patch
It's been raised in the installer across the board, so adapt it here
too.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* new patch
pve-installation.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pve-installation.adoc b/pve-installation.adoc
index 869a879..0ff
.. in accordance with current NIST recommendations [0].
It's 2024; so reasonable to expect an 8-character-password at the
minimum.
While at it, refactor the `InstallRootPassword` struct into an enum, as
suggested by Stefan.
[0] https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver
Signed-o
It's been raised in the installer across the board, so adapt it here
too.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* new patch
docs/using-the-installer.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/using-the-installer.rst b/docs/using-the-installer.r
It's been raised in the installer across the board, so adapt it here
too.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* new patch
pmg-installation.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pmg-installation.adoc b/pmg-installation.adoc
index 4209784..484
It's more appropriate for that type of data, since only one of both
variants is ever allowed to be set. Makes it also a bit more ergonomic
to handle.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* new patch
proxmox-auto-installer/src/utils.rs | 15 +++
proxmox-installer-
This idea came to light while talking with Shannon about #5756 [0].
It is 2024, so raising the minimum length for the root password as
entered during the installation from 5 to 8 characters seems very
sensible. NIST also recommends a minimum length of 8 characters for
passwords [1].
See also the
.. in accordance with current NIST recommendations [0].
It's 2024; so reasonable to expect an 8-character-password at the
minimum.
[0] https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* rebased on latest master
* added note abou
From: Fabian Grünbichler
according to the schema, else some combinations of migration / guest /
storage settings will fail validation:
2024-05-15 11:48:51 ERROR: migration_snapshot: type check ('boolean') failed -
got ''
since this is client / source side, remote migrations to a remote node
wi
On Tue Nov 26, 2024 at 11:21 AM CET, Thomas Lamprecht wrote:
> Am 26.11.24 um 10:27 schrieb Shannon Sterz:
> > actually i needed to adapt this to add support for attachments, which
> > require reworking the multipart logic a bit too. i can factor that out
> > into it's own `proxmox-sendmail` crate
Until now, the reported smart value is returned unconditionally, even
if the drive might report an `UNKNOWN` status.
To allow for better handling of the unknown smart state, also return
the utils helper text in that case. This allows for better handling
of e.g. conditionally showing the smart value
Am 29.11.24 um 09:59 schrieb Lukas Wagner:
> This fixes the error:
> unknown permission test at /usr/share/perl5/PVE/RPCEnvironment.pm line 536.
> (500)
> which occured when trying to create or update a notification target.
>
> The cause was a permission 'check' parameter for the API handlers w
Do not allow to open the smart values window by either double clicking
the record or clicking the show button, if the selected drives status
is unknown.
Fetching the smart values for such devices might fail. Devices which
do not support this can be, e.g. USB pen drives used as removable
datastores
This fixes the error:
unknown permission test at /usr/share/perl5/PVE/RPCEnvironment.pm line 536.
(500)
which occured when trying to create or update a notification target.
The cause was a permission 'check' parameter for the API handlers which was
nested
one level too deep by accident.
This
36 matches
Mail list logo
