Since commit a6f5b35 ("replication: prepare: include volumes without
snapshots in the result"), attempts would be made to remove previous
replication snapshots from volumes on which they didn't exist. This
was noticed by Thomas since the output of a replication test in
pve-manager changed.
The iss
This reverts commit 3a259c22e64ff22049856256a1dad643439c79ef.
There was an oversight with recent replication fixes that led to
attempting to remove snapshots that do not exist (in more scenarios).
While not an issue with real consequences, it's confusing to users.
This has since been fixed by pve-
Am 17.04.24 um 15:07 schrieb Dominik Csapak:
> On 4/17/24 12:52, Fiona Ebner wrote:
>> Am 16.04.24 um 15:18 schrieb Dominik Csapak:
>>>
>>> we currently extract into the import storage in a directory named:
>>> `.tmp__` which should not clash with concurrent
>>> operations (though we do ex
Am 18.04.24 um 09:22 schrieb Fiona Ebner:
diff --git a/src/PVE/Storage.pm b/src/PVE/Storage.pm
index f8ea93d..bc073ef 100755
--- a/src/PVE/Storage.pm
+++ b/src/PVE/Storage.pm
@@ -2189,4 +2189,63 @@ sub get_import_metadata {
return $plugin->get_import_metadata($sc
Am 17.04.24 um 15:14 schrieb Dominik Csapak:
> On 4/17/24 13:32, Fiona Ebner wrote:
>> Am 16.04.24 um 15:18 schrieb Dominik Csapak:
>>> use the standards info about the ostypes to map to our own
>>> (see comment for link to the relevant part of the dmtf schema)
>>>
>>> every type that is not listed
Am 17.04.24 um 16:55 schrieb Thomas Lamprecht:
> Am 15/04/2024 um 14:48 schrieb Fiona Ebner:
>> diff --git a/src/PVE/Storage/Plugin.pm b/src/PVE/Storage/Plugin.pm
>> index 22a9729..5f49830 100644
>> --- a/src/PVE/Storage/Plugin.pm
>> +++ b/src/PVE/Storage/Plugin.pm
>> @@ -205,6 +205,14 @@ my $defau
Signed-off-by: Alexander Zeidler
---
PVE/API2/APT.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/PVE/API2/APT.pm b/PVE/API2/APT.pm
index 54121ec2..4ab6da60 100644
--- a/PVE/API2/APT.pm
+++ b/PVE/API2/APT.pm
@@ -759,6 +759,7 @@ __PACKAGE__->register_method({
push @list, sort $byv
Signed-off-by: Alexander Zeidler
---
bin/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bin/Makefile b/bin/Makefile
index 180a91b5..aa149c06 100644
--- a/bin/Makefile
+++ b/bin/Makefile
@@ -66,10 +66,10 @@ pve6to7.1:
pve7to8.1:
printf ".TH PVE7TO8
when the state is "Installed", including not correctly installed, but
not for (residual) "ConfigFiles".
The information
* can be inaccurate for offline nodes or when using POM.
* is included in pveversion so it can also be used on public channels
like the forum. The current System Report include
to only match those that are correct/accepted by their software
Signed-off-by: Alexander Zeidler
---
PVE/Report.pm | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/PVE/Report.pm b/PVE/Report.pm
index 9c46aa9b..53ffdcbb 100644
--- a/PVE/Report.pm
+++ b/PVE/Report.pm
On Thu Apr 18, 2024 at 9:44 AM CEST, Alexander Zeidler wrote:
> Signed-off-by: Alexander Zeidler
> ---
> bin/Makefile | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/bin/Makefile b/bin/Makefile
> index 180a91b5..aa149c06 100644
> --- a/bin/Makefile
> +++ b/bin/Mak
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> introducing a seperate regex that only contains ova, since
s/seperate/separate/
> upload/downloading ovfs does not make sense (since the disks are then
> missing).
>
> Signed-off-by: Dominik Csapak
With my single comment below addressed:
Reviewed
Am 18/04/2024 um 10:03 schrieb Stefan Sterz:
>> + before, and during the upgrade of a Proxmox VE system.\n" >> $@.tmp
>
> i know this is pre-existing, but since you are touching this anyway: the
> comma here is odd, if this was supposed to be an oxford comma (or serial
> comma), please be awar
Gave this a test with:
Accept-encoding: deflate
Accept-encoding: deflate, gzip
Accept-encoding: foobar
Everything worked as expected, the first case returned a zlib
compressed file, the second gzip and the third just plaintext.
Consider this
Tested-by: Folke Gleumes
On Wed, 2024-04-17 at 13:31
Am 18/04/2024 um 09:38 schrieb Fiona Ebner:
> I was thinking, users might stumble upon this e.g. with "man pvesm", and
> then try it for storages like NFS and wonder why it doesn't work. With
> the "options" option we also explicitly mention NFS/CIFS. I'll send a v2
> without mentioning PBS/ESXi if
Am 11/04/2024 um 15:44 schrieb Fabian Grünbichler:
> if $storage && $format eq 'raw' => no noacl ?
shouldn't this branch be taken if the format is _not_ raw, as only in that
case it might not use ext4?
___
pve-devel mailing list
pve-devel@lists.proxmo
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> @@ -355,9 +361,21 @@ ovf:Item[rasd:InstanceID='%s']/rasd:ResourceType",
> $controller_id);
>
> $qm->{boot} = "order=" . join(';', @$boot);
>
> +my $nic_id = dtmf_name_to_id('Ethernet Adapter');
> +my $xpath_find_nics =
> "/ovf:Envelo
Am 18/04/2024 um 09:06 schrieb Fiona Ebner:
> Since commit a6f5b35 ("replication: prepare: include volumes without
> snapshots in the result"), attempts would be made to remove previous
> replication snapshots from volumes on which they didn't exist. This
> was noticed by Thomas since the output of
This patch is for enabling AMD SEV (Secure Encrypted
Virtualization) support in QEMU.
VM-Config-Examples:
amd_sev: type=std,nodbg=1,noks=1
amd_sev: es,nodbg=1,kernel-hashes=1
Node-Config-Example (gets generated automatically):
amd_sev: cbitpos=47,reduced-phys-bios=1
kernel-hashes, reduced-phys-b
add documentation for the "[PATCH qemu-server] config: QEMU AMD SEV enable"
patch.
Signed-off-by: Markus Frank
---
v4:
* added text that SEV-ES is experimental
qm.adoc | 114
1 file changed, 114 insertions(+)
diff --git a/qm.adoc b/qm.ad
On Thu Apr 18, 2024 at 9:44 AM CEST, Alexander Zeidler wrote:
> when the state is "Installed", including not correctly installed, but
> not for (residual) "ConfigFiles".
>
> The information
> * can be inaccurate for offline nodes or when using POM.
> * is included in pveversion so it can also be us
On Thu Apr 18, 2024 at 10:13 AM CEST, Thomas Lamprecht wrote:
> Am 18/04/2024 um 10:03 schrieb Stefan Sterz:
> >> + before, and during the upgrade of a Proxmox VE system.\n" >> $@.tmp
> >
> > i know this is pre-existing, but since you are touching this anyway: the
> > comma here is odd, if this w
Commit 7020491 ("esxi: add 'port' config parameter") started using
the 'port' option in a second plugin, but the definition stayed in the
PBS plugin. Avoid the hidden dependency and move the definition to the
base plugin instead.
It is necessary to mark it as optional or it would be required alway
On April 17, 2024 4:35 pm, Filip Schauer wrote:
> Do not use the 'noacl' mount option when mounting a container disk with
> an ext4 file system. The option was removed from the kernel in commit
> 2d544ec923db
>
> Signed-off-by: Filip Schauer
> ---
> Changes since v3:
> * Simplify ext4 detection
>
On 17/04/2024 13:31, Maximiliano Sandoval wrote:
> [...]
> - $headers->{'Accept-Encoding'} = 'gzip' if ($reqstate->{accept_gzip} &&
> $self->{compression});
> + if ($self->{compression}) {
> + if ($reqstate->{accept_deflate} && $reqstate->{accept_gzip}) {
> + $headers->
s/btfs/btrfs/
What about GlusterFS? Or is more required to add it there?
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> and reuse the DirPlugin implementation
>
> Signed-off-by: Dominik Csapak
Reviewed-by: Fiona Ebner
___
pve-devel mailing list
pv
On April 18, 2024 10:17 am, Thomas Lamprecht wrote:
> Am 11/04/2024 um 15:44 schrieb Fabian Grünbichler:
>> if $storage && $format eq 'raw' => no noacl ?
>
> shouldn't this branch be taken if the format is _not_ raw, as only in that
> case it might not use ext4?
>
if the format is raw (presumed
Just quick three notes inline; nits other than the crate thing.
Did not review in depth, LGTM overall tho.
On Wed, Apr 17, 2024 at 02:31:08PM +0200, Aaron Lauterer wrote:
[..]
> diff --git a/proxmox-autoinst-helper/Cargo.toml
> b/proxmox-autoinst-helper/Cargo.toml
> index 2a88c0f..75399e0 100644
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> the api part was never in use by anything
>
We don't know for sure if there is not some external client that makes
use of it. But I also think we can drop it and wait for somebody to
complain.
> Signed-off-by: Dominik Csapak
Reviewed-by: Fiona Ebn
On April 18, 2024 9:22 am, Fiona Ebner wrote:
> Am 17.04.24 um 15:07 schrieb Dominik Csapak:
>> On 4/17/24 12:52, Fiona Ebner wrote:
>>> Am 16.04.24 um 15:18 schrieb Dominik Csapak:
we currently extract into the import storage in a directory named:
`.tmp__` which should not cla
On 4/18/24 10:52, Fiona Ebner wrote:
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
the api part was never in use by anything
We don't know for sure if there is not some external client that makes
use of it. But I also think we can drop it and wait for somebody to
complain.
Signed-off-by: Dom
Am 18.04.24 um 10:57 schrieb Dominik Csapak:
> On 4/18/24 10:52, Fiona Ebner wrote:
>> Am 16.04.24 um 15:19 schrieb Dominik Csapak:
>>> the api part was never in use by anything
>>>
>>
>> We don't know for sure if there is not some external client that makes
>> use of it. But I also think we can dr
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> and delete it here (incl tests; they live in pve-storage now).
>
> Signed-off-by: Dominik Csapak
Reviewed-by: Fiona Ebner
> diff --git a/PVE/CLI/qm.pm b/PVE/CLI/qm.pm
> index b105830f..d1d35800 100755
> --- a/PVE/CLI/qm.pm
> +++ b/PVE/CLI/qm.pm
>
On 2024-04-18 10:48, Christoph Heiss wrote:
Just quick three notes inline; nits other than the crate thing.
Did not review in depth, LGTM overall tho.
On Wed, Apr 17, 2024 at 02:31:08PM +0200, Aaron Lauterer wrote:
[..]
diff --git a/proxmox-autoinst-helper/Cargo.toml
b/proxmox-autoinst-he
Add support for compressing the body of responses with
`Content-Encoding: deflate` following [RFC9110]. Note that in this
context `deflate` is actually a "zlib" data format as defined in
[RFC1950].
To preserve the current behavior we prefer `Content-Encoding: gzip`
whenever `gzip` is listed as one
to recognize temporal correlations with network/load/backup/etc issues
Suggested-by: Friedrich Weber
Signed-off-by: Alexander Zeidler
---
v2:
* move away from "general" section
v1: https://lists.proxmox.com/pipermail/pve-devel/2024-March/062346.html
PVE/Report.pm | 6 ++
1 file changed,
* to see if a RAM upgrade is slot/capacity-wise possible
* to spot added/replaced RAM that may now be causing issues
Maximum Capacity: 2 TB
Size: 16 GB Part Number: 18ASF2G72PZ-2G6D1
Size: 16 GB Part Number: 18ASF2G72PZ-2G6D1
Size: 16 GB Part Number: 18A
to get a first clue for debugging passthrough and similar issues, when
no dmesg output has been provided yet.
Signed-off-by: Alexander Zeidler
---
v2:
* move away from dmesg base
* only print kernel command line (boot times can be added by another patch)
v1: https://lists.proxmox.com/pipermail/p
Signed-off-by: Alexander Zeidler
---
v2:
* newly added
PVE/Report.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/Report.pm b/PVE/Report.pm
index 9b6cd95c..1ed91c8e 100644
--- a/PVE/Report.pm
+++ b/PVE/Report.pm
@@ -39,6 +39,7 @@ my $init_report_cmds = sub {
sub { dir
with their details as well as pinned packages. Omit the "origin"
lines, as their value is already visible in the URLs.
# apt-cache policy ...
Package files:
100 /var/lib/dpkg/status
release a=now
500 https://enterprise.proxmox.com/debian/pve bookworm/pve-enterprise amd64
Packages
While using keywords (-t bios,...) would be possible, depending on the
server it also bloats the report with uninteresting information,
hiding the relevant.
Therefore the non-grouped, specific number types are used. Where we
only need specific information, not serial numbers etc., we print the
inf
Successful boots which crashed somehow and sometime afterwards, will
show the same "until" value ("still running" or timestamp) as the next
following boot(s). The most recent boot from such a sequence of
duplicated "until" lines, has not been crashed or not yet.
Example output where only the boot
Sorry, this is of course v2.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Am 18/04/2024 um 10:48 schrieb Fabian Grünbichler:
> On April 18, 2024 10:17 am, Thomas Lamprecht wrote:
>> Am 11/04/2024 um 15:44 schrieb Fabian Grünbichler:
>>> if $storage && $format eq 'raw' => no noacl ?
>>
>> shouldn't this branch be taken if the format is _not_ raw, as only in that
>> case i
ok after a bit of thinking and discussing off-list
the plan to go forward from my side is this:
(please tell if there is something obviously wrong with it or you'd
strongly prefer something differently)
extract on demand vs on upload:
i'd go with extract on demand because managing the extractio
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> @@ -391,6 +392,13 @@ my sub create_disks : prototype($$) {
>
> $needs_creation = $live_import;
>
> + if (PVE::Storage::copy_needs_extraction($source)) { # needs
> extraction beforehand
> + print "e
On 4/18/24 11:41, Fiona Ebner wrote:
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
@@ -391,6 +392,13 @@ my sub create_disks : prototype($$) {
$needs_creation = $live_import;
+ if (PVE::Storage::copy_needs_extraction($source)) { # needs extraction beforehand
+
Am 18.04.24 um 11:48 schrieb Dominik Csapak:
> On 4/18/24 11:41, Fiona Ebner wrote:
>> Am 16.04.24 um 15:19 schrieb Dominik Csapak:
>>> @@ -391,6 +392,13 @@ my sub create_disks : prototype($$) {
>>> $needs_creation = $live_import;
>>> + if (PVE::Storage::copy_needs_ex
On 4/18/24 11:55, Fiona Ebner wrote:
Am 18.04.24 um 11:48 schrieb Dominik Csapak:
On 4/18/24 11:41, Fiona Ebner wrote:
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
@@ -391,6 +392,13 @@ my sub create_disks : prototype($$) {
$needs_creation = $live_import;
+ if (
Am 18.04.24 um 11:58 schrieb Dominik Csapak:
> On 4/18/24 11:55, Fiona Ebner wrote:
>>
>>
>> Am 18.04.24 um 11:48 schrieb Dominik Csapak:
>>> On 4/18/24 11:41, Fiona Ebner wrote:
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> @@ -391,6 +392,13 @@ my sub create_disks : prototype($$)
I am not sure how often we actually need that information as it can add
quite a bit of additional lines in the report in larger machines with
many memory slots.
It might be better to keep that command in a cheatsheet to ask for it if
actually needed instead of polluting the report :)
On 202
gave the series a test by creating a system report on my local machine.
looks good and contains usefull additional information.
The only thing I am not so sure about, is the memory dimm info (patch 6).
Reviewed-By: Aaron Lauterer
Tested-By: Aaron Lauterer
On 2024-04-18 11:16, Alexander Zei
On 4/18/24 11:16, Alexander Zeidler wrote:
> * to see if a RAM upgrade is slot/capacity-wise possible
> * to spot added/replaced RAM that may now be causing issues
>
> Maximum Capacity: 2 TB
> Size: 16 GB Part Number: 18ASF2G72PZ-2G6D1
> Size: 16 GB Part Number: 18ASF2G72
On 4/18/24 11:16, Alexander Zeidler wrote:
> While using keywords (-t bios,...) would be possible, depending on the
> server it also bloats the report with uninteresting information,
> hiding the relevant.
>
> Therefore the non-grouped, specific number types are used. Where we
> only need specific
Am 18.04.24 um 11:27 schrieb Dominik Csapak:
> ok after a bit of thinking and discussing off-list
> the plan to go forward from my side is this:
>
> (please tell if there is something obviously wrong with it or you'd
> strongly prefer something differently)
>
> extract on demand vs on upload:
>
Am 18/04/2024 um 10:25 schrieb Markus Frank:
> This patch is for enabling AMD SEV (Secure Encrypted
> Virtualization) support in QEMU.
>
> VM-Config-Examples:
> amd_sev: type=std,nodbg=1,noks=1
> amd_sev: es,nodbg=1,kernel-hashes=1
>
> Node-Config-Example (gets generated automatically):
> amd_sev
On 4/18/24 11:16, Alexander Zeidler wrote:
> Successful boots which crashed somehow and sometime afterwards, will
> show the same "until" value ("still running" or timestamp) as the next
> following boot(s). The most recent boot from such a sequence of
> duplicated "until" lines, has not been crash
On 4/18/24 11:16, Alexander Zeidler wrote:
> to get a first clue for debugging passthrough and similar issues, when
> no dmesg output has been provided yet.
>
> Signed-off-by: Alexander Zeidler
> ---
> v2:
> * move away from dmesg base
> * only print kernel command line (boot times can be added b
On 4/18/24 12:35, Fiona Ebner wrote:
Am 18.04.24 um 11:27 schrieb Dominik Csapak:
ok after a bit of thinking and discussing off-list
the plan to go forward from my side is this:
(please tell if there is something obviously wrong with it or you'd
strongly prefer something differently)
extract o
Am 18.04.24 um 13:10 schrieb Dominik Csapak:
> On 4/18/24 12:35, Fiona Ebner wrote:
>> Am 18.04.24 um 11:27 schrieb Dominik Csapak:
>>> ok after a bit of thinking and discussing off-list
>>> the plan to go forward from my side is this:
>>>
>>> (please tell if there is something obviously wrong wi
On April 18, 2024 12:35 pm, Fiona Ebner wrote:
> Am 18.04.24 um 11:27 schrieb Dominik Csapak:
>> ok after a bit of thinking and discussing off-list
>> the plan to go forward from my side is this:
>>
>> (please tell if there is something obviously wrong with it or you'd
>> strongly prefer something
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
> diff --git a/www/manager6/window/UploadToStorage.js
> b/www/manager6/window/UploadToStorage.js
> index 3c5bba88..79a6e8a6 100644
> --- a/www/manager6/window/UploadToStorage.js
> +++ b/www/manager6/window/UploadToStorage.js
> @@ -11,6 +11,7 @@ Ext.defi
On 4/18/24 13:20, Fiona Ebner wrote:
Am 16.04.24 um 15:19 schrieb Dominik Csapak:
diff --git a/www/manager6/window/UploadToStorage.js
b/www/manager6/window/UploadToStorage.js
index 3c5bba88..79a6e8a6 100644
--- a/www/manager6/window/UploadToStorage.js
+++ b/www/manager6/window/UploadToStorage.j
Am 18.04.24 um 13:23 schrieb Dominik Csapak:
> On 4/18/24 13:20, Fiona Ebner wrote:
>> Am 16.04.24 um 15:19 schrieb Dominik Csapak:
>>> diff --git a/www/manager6/window/UploadToStorage.js
>>> b/www/manager6/window/UploadToStorage.js
>>> index 3c5bba88..79a6e8a6 100644
>>> --- a/www/manager6/window/
This new subcommand makes it possible to prepare an ISO to use it for an
automated installation.
It is possible to control the behavior of the resulting automated ISO
with optional parameters.
If no target file is specified, the new ISO will be named with suffixes
to indicate it as automated and a
On Thu, 2024-04-18 at 12:24 +0200, Mira Limbeck wrote:
> Would it be possible to align these correctly, or just use a single
> space between type and value?
> I'd prefer explicit commands like:
Better formatting can of course be achieved, see the adapted example below,
followed by your mentioned
Am 18/04/2024 um 11:16 schrieb Maximiliano Sandoval:
> Add support for compressing the body of responses with
> `Content-Encoding: deflate` following [RFC9110]. Note that in this
> context `deflate` is actually a "zlib" data format as defined in
> [RFC1950].
>
> To preserve the current behavior we
with a small style follow-up, thanks!
create_base prints a warning (before this patch as well):
> WARNING: Combining activation change with other commands is not advised.
maybe we could get rid of that one? I guess it doesn't like `-an`
combined with other stuff..
On December 19, 2023 3:03 pm,
On Thu, 2024-04-18 at 12:16 +0200, Aaron Lauterer wrote:
> I am not sure how often we actually need that information as it can add
> quite a bit of additional lines in the report in larger machines with
> many memory slots.
Good point. So in this case we could simply compact the output by counti
On Thu, 2024-04-18 at 12:20 +0200, Mira Limbeck wrote:
> On 4/18/24 11:16, Alexander Zeidler wrote:
> > * to see if a RAM upgrade is slot/capacity-wise possible
> > * to spot added/replaced RAM that may now be causing issues
> >
> > Maximum Capacity: 2 TB
> > Size: 16 GB Part Number: 1
Am 18/04/2024 um 10:48 schrieb Christoph Heiss:
> Do we really need _yet another_ crate dependency for that? Below is a
> check / bail! anyway when running the command proper.
>
> And if we really want a explicit check beforehand, I'd just do something
> like
>
> fn which(name: &str) -> Result<
The previous wording made it sound like all "visible" tasks were
aborted, which is not the case: A user with Sys.Audit but without
Sys.Modify may see a task that was started by a different user, but
overrule-shutdown would not abort the task.
Change wording to better reflect that not all visible t
Add missing spaces and full-stops and wrap strings according to Perl
style guide.
Signed-off-by: Friedrich Weber
---
PVE/API2/Qemu.pm | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 6c9e883..00cd907 100644
--- a/PVE/API2/Qemu
All patches are optional:
- 1/4 fixes spacing and punctuation in the qmshutdown/qmstop descriptions
- 2/4 rewords the overrule-shutdown description for VMs
- 3/4 is the same change for containers
- 4/4 adds a usage example for qm stop -overrule-shutdown to the docs
qemu-server:
Friedrich Weber (
The previous wording made it sound like all "visible" tasks were
aborted, which is not the case: A user with Sys.Audit but without
Sys.Modify may see a task that was started by a different user, but
overrule-shutdown would not abort the task.
Change wording to better reflect that not all visible t
Signed-off-by: Friedrich Weber
---
qm.adoc | 7 +++
1 file changed, 7 insertions(+)
diff --git a/qm.adoc b/qm.adoc
index 45e3a57..42c26db 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -1839,6 +1839,13 @@ Same as above, but only wait for 40 seconds.
# qm shutdown 300 && qm wait 300 -timeout 40
Am 17/04/2024 um 16:35 schrieb Filip Schauer:
> Do not use the 'noacl' mount option when mounting a container disk with
> an ext4 file system. The option was removed from the kernel in commit
> 2d544ec923db
>
> Signed-off-by: Filip Schauer
> ---
> Changes since v3:
> * Simplify ext4 detection
> *
Signed-off-by: Stoiko Ivanov
---
Just had the opportunity to try this on a testsystem - it worked flawlessly :)
I did consider dropping the explicit list of packages and replace it by the
metapackage only, but think that the additional explanation of how they
interact is worth keeping.
system-b
On Thu, 2024-04-18 at 12:43 +0200, Mira Limbeck wrote:
> On 4/18/24 11:16, Alexander Zeidler wrote:
> > Successful boots which crashed somehow and sometime afterwards, will
> > show the same "until" value ("still running" or timestamp) as the next
> > following boot(s). The most recent boot from su
On Thu, 2024-04-18 at 13:05 +0200, Mira Limbeck wrote:
> On 4/18/24 11:16, Alexander Zeidler wrote:
> > to get a first clue for debugging passthrough and similar issues, when
> > no dmesg output has been provided yet.
> >
> > Signed-off-by: Alexander Zeidler
> > ---
> > v2:
> > * move away from d
v2 of this series:
[PATCH manager 1/7] report: add kernel command line from current boot
https://lists.proxmox.com/pipermail/pve-devel/2024-April/063282.html
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailm
Mention and briefly explain it. The main part of the documentation will
live in the Wiki for now as it applies to not just Proxmox VE.
Signed-off-by: Aaron Lauterer
---
pve-installation.adoc | 18 ++
1 file changed, 18 insertions(+)
diff --git a/pve-installation.adoc b/pve-insta
## Introduction
This RFC provides a drop-in replacement for the current pve-firewall package
that is based on Rust and nftables.
It consists of three crates:
* proxmox-ve-config
for parsing firewall and guest configuration files, as well as some helpers
to access host configuration (particular
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/src/firewall/types/group.rs | 36 +++
proxmox-ve-config/src/firewall/types/mod.rs | 2 ++
2 files changed, 38 insertions(+)
create mode
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/src/firewall/parse.rs | 52 ++
proxmox-ve-config/src/firewall/types/alias.rs | 160 ++
proxmox-ve-config/src/firewall/types/mod.r
Includes types for all kinds of IP values that can occur in the
firewall config. Additionally, FromStr implementations are available
for parsing from the config files.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxm
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/src/firewall/types/ipset.rs | 349 ++
proxmox-ve-config/src/firewall/types/mod.rs | 2 +
2 files changed, 351 insertions(+)
create mode
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
Cargo.toml | 1 +
proxmox-nftables/Cargo.toml | 16
proxmox-nftables/src/lib.rs | 0
3 files changed, 17 insertions(+)
create mode 100644
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/src/firewall/cluster.rs | 374 ++
proxmox-ve-config/src/firewall/mod.rs | 1 +
2 files changed, 375 insertions(+)
create mode 100
Some types from the firewall configuration map directly onto nftables
expressions. For those we implement conversion traits so we can
conveniently convert between the configuration types and the
respective nftables types.
Those are guarded behind a feature so the nftables crate can be used
standal
Since the basic format of cluster, host and guest firewall
configurations is the same, we create a generic parser that can handle
the common config format. The main difference is in the available
options, which can be passed via a generic parameter.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carr
Some parts of the firewall config map directly to nftables objects, so
we introduce conversion traits for convenient conversion into the
respective nftables objects / types.
They are guarded behind a feature, so the nftables crate can be used
standalone without depending on the proxmox-ve-config c
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
Cargo.toml | 1 +
proxmox-firewall/Cargo.toml | 17 +
proxmox-firewall/src/main.rs | 5 +
3 files changed, 23 insertions(+)
create m
Currently this is parsing the config files via the filesystem. In the
future we could also get this information from pmxcfs directly via
IPC which should be more performant, particularly for a large number
of VMs.
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumill
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-ve-config/resources/macros.json | 914
proxmox-ve-config/src/firewall/fw_macros.rs | 69 ++
proxmox-ve-config/src/firewall/mod.rs |
Reviewed-by: Lukas Wagner
Reviewed-by: Max Carrara
Co-authored-by: Wolfgang Bumiller
Signed-off-by: Stefan Hanreich
---
proxmox-firewall/src/bin/proxmox-firewall.rs | 96
proxmox-firewall/src/lib.rs | 4 +
proxmox-firewall/src/main.rs | 11
Signed-off-by: Stefan Hanreich
---
www/manager6/grid/FirewallOptions.js | 1 +
1 file changed, 1 insertion(+)
diff --git a/www/manager6/grid/FirewallOptions.js
b/www/manager6/grid/FirewallOptions.js
index 0ac9979c4..6aacb47be 100644
--- a/www/manager6/grid/FirewallOptions.js
+++ b/www/manager6/
This is the skeleton for the firewall that contains all the base
chains required for the firewall.
The file applies atomically, which means that it flushes all objects
and recreates them - except for the cluster/host/guest chain. This
means that it can be run at any point in time, since it only up
Add a section that explains how to use the new nftables-based
proxmox-firewall.
Signed-off-by: Stefan Hanreich
---
pve-firewall.adoc | 185 ++
1 file changed, 185 insertions(+)
diff --git a/pve-firewall.adoc b/pve-firewall.adoc
index a5e40f9..ec713ea
Add rust types for most of the nftables commands as defined by
libnftables-json [1].
Different commands require different keys to be set for the same type
of object. E.g. deleting an object usually only requires a name +
name of the container (table/chain/rule). Creating an object usually
requires
1 - 100 of 134 matches
Mail list logo
