On 12/12/2023 12:48, Fiona Ebner wrote:
Am 12.12.23 um 11:39 schrieb Filip Schauer:
It's actually not a different binary. qemu-system-i386 is a symlink that
points to qemu-system-x86_64. But still this does indeed break migration
between a node that has this patch applied and another node
On 12/13/23 16:35, Stefan Hanreich wrote:
> Since LVM 2.03.15 RBD devices are also scanned by default [1]. This
> can lead to guest volumes being recognized and displayed on the host
> when using KRBD for RBD-backed disks. In order to prevent this we add
> an additional filter to the LVM config
Patch v5 is available:
https://lists.proxmox.com/pipermail/pve-devel/2023-December/061079.html
On 13/12/2023 17:53, Filip Schauer wrote:
Instead of starting a VM with a 32-bit CPU type and a 64-bit OVMF image,
throw an error before starting the VM telling the user that OVMF is not
supported on
Patch v5 is available:
https://lists.proxmox.com/pipermail/pve-devel/2023-December/061079.html
On 12/12/2023 12:12, Fiona Ebner wrote:
Am 12.12.23 um 11:58 schrieb Filip Schauer:
Instead of starting a VM with a 32-bit CPU type and a 64-bit OVMF image,
throw an error before starting the VM
Instead of starting a VM with a 32-bit CPU type and a 64-bit OVMF image,
throw an error before starting the VM telling the user that OVMF is not
supported on 32-bit CPU types.
To obtain a list of 32-bit CPU types, refer to builtin_x86_defs in
target/i386/cpu.c of QEMU. Exclude any entries that
Instead of starting a VM with a 32-bit CPU type and a 64-bit OVMF image,
throw an error before starting the VM telling the user that OVMF is not
supported on 32-bit CPU types.
To obtain a list of 32-bit CPU types, refer to builtin_x86_defs in
target/i386/cpu.c of QEMU. Exclude any entries that
`Auto-Submitted` is defined in the rfc 5436 [1] and describes how
an automatic response (f.e. ooo replies, etc.) should behave on the
emails. When using `Auto-Submitted: auto-generated` (or any value
other than `none`) automatic replies won't be triggered.
[1]:
For mails forwarded by `proxmox-mail-forward` to an SMTP target, the
original message was nested as a 'message/rfc822' message part.
Originally this approach was chosen to avoid having to rewrite
message headers.
Good email-clients, such as Thunderbird can display these inline.
Other, more limited
This should make the code more cohesive and easier to follow.
No functional changes.
Signed-off-by: Lukas Wagner
Tested-by: Maximiliano Sandoval
---
src/window/NotificationMatcherEdit.js | 186 +-
1 file changed, 92 insertions(+), 94 deletions(-)
diff --git
These changes introduce combogrid pickers for the 'field' and 'value'
form elements for 'match-field' match rules. The 'field' picker shows
a list of all known metadata fields, while the 'value' picker shows a
list of all known values, filtered depending on the current value of
'field'.
The list
Also introduce a local viewModel that is linked to a parent viewModel,
allowing us to move the formulas to the panel.
This should make the code more cohesive and easier to follow.
No functional changes.
Signed-off-by: Lukas Wagner
Tested-by: Maximiliano Sandoval
---
- The man page warns about the usage of `hostname -f`, since a host
may have multiple domains (or none at all)
- The fallback PVE::INotify::nodename() already only returned the
hostname without the domain part
- Fencing notifications didn't include the domain part anyway
This may result
This patch series attempts to improve the user experience when creating
notification matchers.
Some of the noteworthy changes:
- Fixup inconsistent 'hostname' field. Some notification events sent
the hostname including a domain, while other did not.
This series unifies the behavior, now the
This was a bit inconsistent between the different notification types:
- APT/VZDump included the domain part
- fence notifications did not
A decision has been made to unify this by removing the domain part
from APT/VZDump notifications.
Signed-off-by: Lukas Wagner
---
notifications.adoc | 2
This allows users to create notification match rules for specific
replication jobs, if they so desire.
Signed-off-by: Lukas Wagner
---
PVE/API2/Replication.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/API2/Replication.pm b/PVE/API2/Replication.pm
index
This is useful for creating matchers based on the 'backup-job'
metadata field.
Signed-off-by: Lukas Wagner
---
www/manager6/dc/Backup.js | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/www/manager6/dc/Backup.js b/www/manager6/dc/Backup.js
index 4beb84c0..fb4df0a7 100644
Signed-off-by: Lukas Wagner
---
proxmox-notify/src/lib.rs | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/proxmox-notify/src/lib.rs b/proxmox-notify/src/lib.rs
index 1fb9623..f3ee3ad 100644
--- a/proxmox-notify/src/lib.rs
+++ b/proxmox-notify/src/lib.rs
@@
This new API route returns known notification metadata fields and
a list of known possible values. This will be used by the UI to
provide suggestions when adding/modifying match rules.
Signed-off-by: Lukas Wagner
---
PVE/API2/Cluster/Notifications.pm | 152 ++
1 file
Also introduce a local viewModel that is linked to a parent viewModel,
allowing us to move the formulas to the panel.
This should make the code more cohesive and easier to follow.
No functional changes.
Signed-off-by: Lukas Wagner
Tested-by: Maximiliano Sandoval
---
Signed-off-by: Lukas Wagner
---
notifications.adoc | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/notifications.adoc b/notifications.adoc
index 62a1cee..00776a5 100644
--- a/notifications.adoc
+++ b/notifications.adoc
@@ -221,11 +221,16 @@ configurable
This allows one configure the clear trigger to be shown, even if
'allowBlank' is set false. This can be useful if one has a
non-editable combogrid where the value is set to something not
present in the store. Example: Match rule editing, one selects
a backup job to be match. If the backup job is
Signed-off-by: Lukas Wagner
---
notifications.adoc | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/notifications.adoc b/notifications.adoc
index f087dda..62a1cee 100644
--- a/notifications.adoc
+++ b/notifications.adoc
@@ -289,19 +289,22 @@ Notification
Notification match rules are able to match based on the job id, so it
makes sense to display it to the user.
Signed-off-by: Lukas Wagner
---
www/manager6/grid/Replication.js | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/www/manager6/grid/Replication.js
Signed-off-by: Lukas Wagner
---
www/manager6/dc/Backup.js | 1 -
1 file changed, 1 deletion(-)
diff --git a/www/manager6/dc/Backup.js b/www/manager6/dc/Backup.js
index 70903bdc..4beb84c0 100644
--- a/www/manager6/dc/Backup.js
+++ b/www/manager6/dc/Backup.js
@@ -569,7 +569,6 @@
Signed-off-by: Lukas Wagner
---
www/manager6/Utils.js | 12
1 file changed, 12 insertions(+)
diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js
index 63129358..315038e1 100644
--- a/www/manager6/Utils.js
+++ b/www/manager6/Utils.js
@@ -2030,6 +2030,18 @@
The field contains the hostname of the host (without any domain part)
which sends the notification. This field can be used in match-field
match rules.
Signed-off-by: Lukas Wagner
---
PVE/API2/Replication.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/PVE/API2/Replication.pm
This allows us to access us the backup job id in the send_notification
function, where we can set it as metadata for the notification.
Signed-off-by: Lukas Wagner
---
PVE/API2/VZDump.pm | 8
PVE/Jobs/VZDump.pm | 4 +++-
PVE/VZDump.pm | 6 +++---
3 files changed, 14 insertions(+),
For example, one can now use:
match-field exact:type=vzdump,replication
to match on vzdump AND replication events.
Signed-off-by: Lukas Wagner
---
proxmox-notify/src/matcher.rs | 43 +++
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git
This might be useful if somebody wants to match on the new
'backup-job' field in a notification match rule.
Signed-off-by: Lukas Wagner
---
www/manager6/Utils.js | 4
www/manager6/dc/Backup.js | 11 +++
2 files changed, 15 insertions(+)
diff --git a/www/manager6/Utils.js
Signed-off-by: Lukas Wagner
---
PVE/API2/Cluster/Notifications.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Cluster/Notifications.pm
b/PVE/API2/Cluster/Notifications.pm
index 7047f0b1..68fdda2a 100644
--- a/PVE/API2/Cluster/Notifications.pm
+++
Seems like this was forgotten in the initial version. Without it,
it's not really possible to create matchers for forwarded mails.
Signed-off-by: Lukas Wagner
---
Notes:
New in v2.
proxmox-notify/src/lib.rs | 1 +
1 file changed, 1 insertion(+)
diff --git a/proxmox-notify/src/lib.rs
On 12/11/23 13:49, Lukas Wagner wrote:
This patch series attempts to improve the user experience when creating
notification matchers.
Will submit a v2 that includes a fix for a missing 'type' metadata field
for forwarded mails.
--
- Lukas
___
Am 13/12/2023 um 15:49 schrieb Maximiliano Sandoval:
> Tweak some string, improve others.
>
> Signed-off-by: Maximiliano Sandoval
> ---
> es.po | 52 +---
> 1 file changed, 25 insertions(+), 27 deletions(-)
>
>
applied, thanks!
Since LVM 2.03.15 RBD devices are also scanned by default [1]. This
can lead to guest volumes being recognized and displayed on the host
when using KRBD for RBD-backed disks. In order to prevent this we add
an additional filter to the LVM config to avoid scanning RADOS block
devices.
This also
Tweak some string, improve others.
Signed-off-by: Maximiliano Sandoval
---
es.po | 52 +---
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/es.po b/es.po
index 132f82a..98eb007 100644
--- a/es.po
+++ b/es.po
@@ -8,7 +8,7 @@ msgstr
Do not pass the cleanup flag to get_replicatable_volumes() which leads
to replicatable volumes that have the replicate setting turned off to
be part of the result.
Instead pass the noerr flag, because things like missing the
storage-level replicate feature should not lead to an error here.
Suggest an alternative solution by removing the problematic volumes
from the replication target rather than the whole job.
This is helpful if there are multiple replicated volumes to avoid the
need to fully re-sync all volumes in many cases.
Signed-off-by: Fiona Ebner
---
No changes in v2.
Note that PVE::Storage::volume_snapshot_info() will fail when a volume
does not exist, so no non-existing volume will end up in the result
(prepare() is only called with volumes that should exist).
This makes it possible to detect a volume without snapshots in the
result of prepare(), and as a
Improve error when finding a common base snapshot and fix the check if
a snapshot is needed by replication when there are volumes with
replicate setting turned off.
First version:
https://lists.proxmox.com/pipermail/pve-devel/2023-January/055513.html
Changes since v1:
* add an additional fix
39 matches
Mail list logo
