Am 05.02.25 um 17:13 schrieb Gabriel Goller:
> Previously the frr config generation and writing was only done in the
> evpn plugin. This means that it was not possible to create a standalone
> bgp and isis plugin without an evpn plugin in place. (The config would
> just never be written.) To fix th
Am 07.02.25 um 14:40 schrieb Stefan Hanreich:
> The conditional assignment caused falsy values to be converted to
> undef when comparing them. This led to the behavior that configuration
> values that are interpreted by perl as falsy would get wrongly
> compared and always show up as pending change
Adds test cases for the alloc_disk wrapper subroutine to ensure that:
- zero-sized volumes are allocated as subvols on path-based storages
- non-zero-sized volumes are allocated as raw on path-based storages
- volumes are allocated as raw on btrfs storages without quotas
- volumes are allocated as
Make use of the newly introduced content type assertion helpers in the
preconditions check paths and the call to `vdisk_alloc` in the API
handler for migrating VMs (and its subcommands and `mtunnel` endpoint).
Since the preconditions existed before, adding a content type safeguard
at `vdisk_alloc`
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/LXC.pm | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
index 51457ec..1152131 100644
--- a/src/PVE/LXC.pm
+++ b/src/PVE/LXC.pm
@@ -2157,6 +2157,7 @@ sub alloc_disk {
Make use of newly introduced content type assertion helpers in the
preconditions check path in the API handler for creating a container.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/API2/LXC.pm | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/PVE
Update the call to `PVE::Storage::vdisk_alloc` to the updated function
signature, which moves the optional argument `$name` (as it may be
passed as undefined), to the optional hash argument at the end of the
argument list.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/LXC.pm |
Make use of the newly introduced content type assertion helpers in the
precondition check path and the call to `vdisk_alloc` in the wrapper for
allocating container's disks.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/LXC.pm | 7 ---
1 file changed, 4 insertions(+), 3 de
Update any callers of `PVE::Storage::vdisk_alloc` to the updated
function signature, which moves the optional arguments `$fmt` and
`$name` (as these may be passed as undefined), to the optional hash
argument at the end of the argument list.
Signed-off-by: Daniel Kral
---
changes since v1:
- updat
Make use of newly introduced content type assertion helpers in the
preconditions check and preparation path of the migration API handlers.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/API2/LXC.pm| 8 ++--
src/PVE/LXC/Migrate.pm | 13 ++---
2 files changed, 8
Make use of the newly introduced content type assertion helpers at
verifying the added and/or changed container config values, which is
called e.g. in the API handler for updating the container config.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/LXC/Config.pm | 4 +---
1 fil
Make use of the newly introduced content type assertion helpers at
verifying the content type when mounting mountpoints, which have the
format "raw" or "iso".
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/LXC.pm | 18 +-
1 file changed, 9 insertions(+), 9 delet
Make use of the newly introduced content type assertion helpers in the
preconditions check paths and the call to `vdisk_alloc` in the API
handlers for creating a VM or updating a VM with newly allocated VM,
EFI, TPM and/or cloudinit images.
Since the preconditions existed before, adding a content
Make use of the newly introduced content type assertion helpers in the
preconditions check paths and the call to `vdisk_alloc` in the API and
CLI handler for restoring VMs to a specified target storage.
Since the preconditions existed before, adding a content type safeguard
at `vdisk_alloc` does n
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/LXC.pm | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
index 44e28fc..51457ec 100644
--- a/src/PVE/LXC.pm
+++ b/src/PVE/LXC.pm
@@ -2158,7 +2158,11 @@ sub alloc_disk {
Make use of the newly introduced content type assertion helpers in the
preconditions check paths and the call to `vdisk_alloc` in the API
handlers for cloning VMs to another storage and moving a VM disk to
another storage with the newly introduced helper.
Since the preconditions existed before, ad
Since 0541eeb8 ("use property strings for drive options") the user input
of a volume with allocation support must be a pair of a PVE-managed
storage and an arbitrary string (i.e. the volume name or the size of a
new disk in GB) [0]. Therefore, the `$volid` must always be the string
"$storeid:$volna
Improve the error message when a VM start fails due to a volume storage
not supporting the volume's required content type by prefixing it with
the disk handle (e.g. scsi0).
Signed-off-by: Daniel Kral
---
changes since v1:
- none except relocation of helper
PVE/QemuServer.pm
Remove variable `$size`, which is not used here and likely a copy-paste
redundancy from the `create_disks` subroutine.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
PVE/API2/Qemu.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
Add subroutines for asserting the content types of storages and volumes
to reduce code duplication, e.g. when implementing preconditions in an
API handler before calling vdisk_alloc.
Signed-off-by: Daniel Kral
---
changes since v1:
- moved from qemu-server to pve-storage
- add missing $node param
Asserts whether the target storage supports storing VM images before
moving a VM volume to the target storage.
Without the check in place, a VM volume can be moved to a storage, which
does not support VM images, but won't be able to start since any
attached volume must be stored on a supported sto
Tests whether when running `config_to_command` it will correctly fail
with an error message that a volume cannot be used if the underlying
storage does not support its content type.
Signed-off-by: Daniel Kral
---
changes since v1:
- no changes except removing unrelated diff
test/cfg2cmd/unsuppo
Since there are only two distinct outcomes, i.e. raw format + do_format
and subvol format + needs_chown, break down the conditions to reduce the
branching depth.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/LXC.pm | 13 +
1 file changed, 5 insertions(+), 8 deletio
Factor out the common read-only variables to allow the second call to
`storage_check_enabled` to be below 100 characters.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/LXC/Migrate.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/PVE/LXC/Migrate.p
Make use of the newly introduced content type assertion helpers in the
preconditions check paths and the call to `vdisk_alloc` in the API
handlers for importing VM disks or importing OVF manifests as VMs.
Since the preconditions existed before, adding a content type safeguard
at `vdisk_alloc` does
Add TODO comments to calls to `vdisk_alloc`, which should be done for
consistency, but would be breaking in the current release since both
snapshot state files and fleecing images are allowed on storages, which
do not support VM images and work without errors currently.
Signed-off-by: Daniel Kral
== Description ==
There were (at least) four missing assertions whether the underlying
storage supports the content type that is about the be allocated, but
will fail to start with a volume not being on a storage, which supports
VM images (see `config_to_command` for the existing check):
- when m
Allow a caller to specify the volume's intended content type and assert
whether the specified content type may be stored on the specified
storage before allocating any volume.
Signed-off-by: Daniel Kral
---
changes since v1:
- add assertion at `vdisk_alloc` instead of wrapper `alloc_volume_disk`
Asserts whether the target storage supports storing cloudinit images,
i.e. VM images, before creating a cloudinit image on the target storage.
Without the check in place, a cloudinit image can be created on the
storage, which does not support VM images, but won't be able to start
since any attache
Make any code path with an existent content type assertion use the newly
introduced content type assertion helper.
As those code paths must perform actions on the storage anyway, the
`storage_check_enabled` in the helper subroutine adds an additional
precondition check without breaking the existin
Asserts whether the target storage supports storing VM images before
importing a OVF manifest as a VM to the target storage.
Without the check in place, a VM volume can be imported to a storage,
which does not support VM images, but won't be able to start since any
attached volume must be stored o
Asserts whether the target storage supports storing VM images before
cloning a VM and its volumes to the target storage.
Without the check in place, a VMs volumes can be cloned to a storage,
which does not support VM images, but won't be able to start since any
attached volume must be stored on a
Minor cleanup to reduce the amount of `$param->{...}` to variables in
the upload and download url API handler.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/API2/Storage/Status.pm | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/PV
Moves the optional parameter `name` into an optional hash argument at
the end of the function.
This allows to add more optional arguments in the future and makes the
function call easier to follow when a name is not required.
Signed-off-by: Daniel Kral
---
changes since v1:
- new!
src/PVE/API2
Maximiliano Sandoval writes:
> Maximiliano Sandoval writes:
>
>> Maximiliano Sandoval writes:
>>
>>> The catalog-{lang}.mo files are generated only with strings that are
>>> relevant to the proxmox-datacenter-manager instead of the whole
>>> {lang}.po file. The msgmerge command will produce a
I'm not _that_ familiar (yet) really with the resource mapping and
live-migration code. So I'd not consider this a full in-depth review.
But looking over the patches, nothing odd stood out to me, at least.
Small nit: personally I'd just squash the two pve-docs patches, since
they touch the exact
On Mon Jan 20, 2025 at 3:51 PM CET, Dominik Csapak wrote:
[..]
> diff --git a/PVE/API2/Nodes.pm b/PVE/API2/Nodes.pm
> index 9cdf19db..6fe7a5fd 100644
> --- a/PVE/API2/Nodes.pm
> +++ b/PVE/API2/Nodes.pm
> @@ -2331,11 +2331,23 @@ my $create_migrate_worker = sub {
> $invalidConditions .= joi
Ping!
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
On Mon Jan 20, 2025 at 3:51 PM CET, Dominik Csapak wrote:
[..]
> +my sub get_current_node_mapping {
> +my ($mapping_config, $mapping_name) = @_;
> +
> +my $node = PVE::INotify::nodename();
> +my $devices = PVE::Mapping::PCI::get_node_mapping($mapping_config,
> $mapping_name, $node);
>
On February 10, 2025 4:37 pm, Filip Schauer wrote:
> Allow users with the VM.Config.HWType privilege to configure VirtIO RNG
> devices on VMs with either /dev/urandom or /dev/random as the entropy
> source.
>
> Further introduce hardware RNG device mapping to be able to selectively
> allow non-roo
On February 10, 2025 4:37 pm, Filip Schauer wrote:
> Allow non-root users with the VM.Config.HWType privilege to configure
> /dev/urandom & /dev/random as an entropy source for a VirtIO RNG device.
> /dev/hwrng remains restricted to the root user.
>
> Signed-off-by: Filip Schauer
> ---
> PVE/API
On February 10, 2025 4:37 pm, Filip Schauer wrote:
> This allows a user with the Mapping.Modify privilege on /mapping/hwrng
> to configure a hardware RNG mapping. A less privileged user with the
> Mapping.Use privilege can then pass the mapped hardware RNG device as an
> entropy source to a VirtIO
Am 11.02.25 um 11:17 schrieb Fiona Ebner:
> @Filip, you are more than welcome to ping your fixes after a while,
> especially if they already have T-B and R-B 🙂
Thanks for your reminder on this series. FWIW, in such a case I think
one can also "ping" in the form of a new revision of the patch (seri
Am 25.11.24 um 14:09 schrieb Filip Schauer:
> When mounting volumes as read-only, certain mount options like
> "discard", "lazytime", and "noatime" are either ignored or can cause the
> mount to fail. For example, attempting to mount with "-t zfs" and
> "-o ro,discard" leads to an error: filesystem
Same rationale as in pve-manager commit 5f855ccf ("ui: restore:
improve warning for restoring container with same ID"): it's
surprising to (new) users that all owned mount point volumes are
erased upon container restore, even those that are not currently
selected for backup. This is different from
Same rationale as in pve-manager commit 5f855ccf ("ui: restore:
improve warning for restoring container with same ID"): it's
surprising to (new) users that all owned mount point volumes are
erased upon container restore, even those that are not currently
selected for backup. This is different from
Ping
@Filip, you are more than welcome to ping your fixes after a while,
especially if they already have T-B and R-B :)
Am 25.11.24 um 14:09 schrieb Filip Schauer:
> When mounting volumes as read-only, certain mount options like
> "discard", "lazytime", and "noatime" are either ignored or can cau
Am 11.02.25 um 10:45 schrieb Fiona Ebner:
> Am 10.02.25 um 17:12 schrieb Thomas Lamprecht:
>> Am 18.12.24 um 11:32 schrieb Fiona Ebner:
>>> Signed-off-by: Fiona Ebner
>>> ---
>>> src/PVE/LXC/Migrate.pm | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>>
>>
>> applied, thanks!
>>
>> The first patc
Am 10.02.25 um 17:12 schrieb Thomas Lamprecht:
> Am 18.12.24 um 11:32 schrieb Fiona Ebner:
>> Signed-off-by: Fiona Ebner
>> ---
>> src/PVE/LXC/Migrate.pm | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>>
>
> applied, thanks!
>
> The first patch was already applied by Fabian on 2024-12-19:
>
> h
49 matches
Mail list logo
