--- Begin Message ---
From: Lou Lecrivain
Signed-off-by: lou lecrivain
Tested-by: Stefan Hanreich
Reviewed-by: Stefan Hanreich
---
src/PVE/Network/SDN/Ipams/PVEPlugin.pm | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/PVE/Network/SDN/Ipams/PVEPlugin.pm
b/src/PVE/
--- Begin Message ---
From: Lou Lecrivain
Signed-off-by: lou lecrivain
Tested-by: Stefan Hanreich
Reviewed-by: Stefan Hanreich
---
src/test/run_test_subnets.pl| 24 +---
src/test/run_test_vnets_blackbox.pl | 6 ++
2 files changed, 23 insertions(+), 7 deletions
--- Begin Message ---
From: Lou Lecrivain
(configure_range is now noop)
Signed-off-by: lou lecrivain
Tested-by: Stefan Hanreich
Reviewed-by: Stefan Hanreich
---
src/PVE/Network/SDN/Dhcp.pm | 1 -
src/PVE/Network/SDN/Dhcp/Dnsmasq.pm | 23 ++-
2 files changed, 10 i
--- Begin Message ---
From: Lou Lecrivain
Signed-off-by: lou lecrivain
Tested-by: Stefan Hanreich
Reviewed-by: Stefan Hanreich
---
src/PVE/Network/SDN/Vnets.pm | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/PVE/Network/SDN/Vnets.pm b/src/PVE/Network/SDN/Vnets.pm
ind
Am 13.12.24 um 16:05 schrieb Fiona Ebner:
> Am 13.12.24 um 16:00 schrieb Hannes Dürr:
>> Do I understand you correctly that the feature is not yet ready to be
>> removed from the technology preview?
>
> Yes, IMHO both of the mentioned improvements should be implemented first.
There's an alternati
Am 13.12.24 um 17:30 schrieb Fiona Ebner:
> + run_command(['dd', "if=$file", "bs=64k", "status=progress"], output =>
> '>&'.fileno($fh));
---snip---
> + run_command(['dd', "of=$file", 'bs=64k'], input => '<&'.fileno($fh));
Forgot to mention, I did not test with different block sizes ye
Current export implementations luckily seems to not run into this
issue yet. However, for the upcoming implementation for RBD, mapping a
volume would print the device path to STDOUT, thus messing up the
export stream.
Signed-off-by: Fiona Ebner
---
src/PVE/CLI/pvesm.pm | 5 -
1 file changed,
For now, only 'raw+size' is supported and it's not possible to
export/import with snapshots. The volume or snapshot is mapped using
krbd and then the data is read via 'dd'.
Introducing an 'rbd' transport format might be feasible for more
complete (i.e. with snapshots, incremental) transfer between
From: Max Carrara
This module's purpose is to provide shared functions, constants, etc.
for storage plugins and storage-related operations.
It also contains the `get_deprecation_warning` subroutine that makes
it easier to warn developers and/or plugin authors that a subroutine
will be removed in
Previously, the size was rounded down which, in case of an image with
non-1KiB-aligned sze (only possible for external plugins or manually
created images) would lead to errors when attempting to write beyond
the end of the too small allocated target image.
For image allocation, the size is already
Signed-off-by: Fiona Ebner
---
NOTE: the helper seems a bit brittle and does not distinguish between
the volume not existing and another error. While allocation or
renaming later still fail with an error, improving the helper seems
worthwhile
src/PVE/Storage/RBDPlugin.pm | 17 -
For now, only 'raw+size' is supported and it's not possible to
export/import with snapshots. The volume or snapshot is mapped using
krbd and then the data is read via 'dd'.
Introducing an 'rbd' transport format might be feasible for more
complete (i.e. with snapshots, incremental) transfer between
Signed-off-by: Fiona Ebner
---
src/PVE/Storage/RBDPlugin.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/PVE/Storage/RBDPlugin.pm b/src/PVE/Storage/RBDPlugin.pm
index f45ad3f..680e922 100644
--- a/src/PVE/Storage/RBDPlugin.pm
+++ b/src/PVE/Storage/RBDPlugin.pm
@@ -389,6 +389,7 @@ sub p
Am 17.07.24 um 11:40 schrieb Max Carrara:
> diff --git a/src/PVE/Storage/Makefile b/src/PVE/Storage/Makefile
> index d5cc942..2627062 100644
> --- a/src/PVE/Storage/Makefile
> +++ b/src/PVE/Storage/Makefile
Since I tried to use this, mentioning for completeness, the Makefile is
missing an entry fo
Am 13.12.24 um 16:00 schrieb Hannes Dürr:
> Do I understand you correctly that the feature is not yet ready to be
> removed from the technology preview?
Yes, IMHO both of the mentioned improvements should be implemented first.
> On 12/13/24 15:49, Fiona Ebner wrote:
>> Am 13.12.24 um 15:32 schrie
Do I understand you correctly that the feature is not yet ready to be
removed from the technology preview?
On 12/13/24 15:49, Fiona Ebner wrote:
Am 13.12.24 um 15:32 schrieb Hannes Duerr:
The static load scheduler feature was applied on 17/11/2022 [0] and can
be considered stable now
The tim
Am 13.12.24 um 15:32 schrieb Hannes Duerr:
> The static load scheduler feature was applied on 17/11/2022 [0] and can
> be considered stable now
>
The timing alone doesn't tell much. While there don't seem to be any
real issues with the implementation, it was never fully fleshed out and
there are
The static load scheduler feature was applied on 17/11/2022 [0] and can
be considered stable now
[0]
https://lore.proxmox.com/pve-devel/20221117140018.105004-1-f.eb...@proxmox.com/
Signed-off-by: Hannes Duerr
---
ha-manager.adoc | 2 --
1 file changed, 2 deletions(-)
diff --git a/ha-manager.a
LGTM. Tested with a shell script and a compiled binary, w/ and w/o
sending the `Content-Length` header in the response.
The "Automated Installation" page needs to be updated though, to
reflect:
a) that either shell-scripts or compiled binaries can be used and
b) that the compiled binaries must be
--- Begin Message ---
Re,
> but shouldn't theses ranges be added when the dhcp ranges are submitted
> on subnet create/update api call ? (I'm not 100% sure, but I think it
> was missing a hook to call the sdn api when submitting the dhcp ranges)
Yes, I do think this should be the case too.
BR
__
On 12/13/24 01:23, Tyst Marin wrote:
I'm still not really all that convinced that Map.Modify is better suited over VM.Config.HWType/
Mapping.Use. Mainly as it seems reasonable to expect the requirement/nonrequirement to still be a hw
level config to the vm and that the map should only have the r
21 matches
Mail list logo
