The aim of this patch series is to adapt `proxmox-mail-forward`
so that it forwards emails that were sent to the local root user
through the `proxmox_notify` crate.
A short summary of the status quo:
Any mail that is sent to the local `root` user is forwarded by
postfix to the `proxmox-mail-forwa
The context has now been moved to `proxmox-notify` due to the fact
that we also need it in `proxmox-mail-forward` now.
Signed-off-by: Lukas Wagner
---
Notes:
Changes v2 -> v3:
- No changes
pve-rs/Cargo.toml| 2 +-
pve-rs/src/lib.rs| 7 ++-
pve-rs/src/notif
This commit moves PVEContext from `proxmox-perl-rs` into the
`proxmox-notify` crate, since we now also need to access it from
`promxox-mail-forward`. The context is now hidden behind a feature
flag `pve-context`, ensuring that we only compile it when needed.
This commit adds PBSContext, since we n
This allows us to send notifications for events from daemons that are
not under our control, e.g. zed, smartd, cron. etc...
For mail-based notification targets (sendmail, soon smtp) the mail is
forwarded as is, including all headers.
All other target types will try to parse the email to extra subj
proxmox-schema and proxmox-section config is not required anymore.
add new dependency to proxmox-notify.
Signed-off-by: Lukas Wagner
---
Notes:
Changes v2 -> v3:
- new in v3
debian/control | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debi
Signed-off-by: Lukas Wagner
---
Notes:
Changes v2 -> v3:
- Dropped paragraph about target/policy, since we now do routing in
matchers
notifications.adoc | 16
1 file changed, 16 insertions(+)
diff --git a/notifications.adoc b/notifications.adoc
index 764ec72.
While at it, convert it to a proper `View`-impl, instead of a functional
component.
No functional changes.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* moved separation of progress task function to separate patch
proxmox-tui-installer/src/main.rs | 233 +
No functional changes.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* new patch, separated out from patch #1
* use static member function instead of top-level function
.../src/views/install_progress.rs | 299 +-
1 file changed, 152 insertions(+), 147 dele
This at least gives _some_ feedback to the user he can potentially
report or try to address, instead of a single, hardcoded message.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
.../src/views/install_progress.rs | 33 +--
1 file changed, 23 ins
No functional changes.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* use static member function instead of top-level function
.../src/views/install_progress.rs | 42 ++-
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/proxmox-tui-installer/
No functional changes.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* moved spawn_low_level_installer() to common crate
proxmox-installer-common/src/setup.rs | 22 -
.../src/views/install_progress.rs | 24 ++-
2 files changed, 23 ins
No functional changes.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* use static member function instead of top-level function
.../src/views/install_progress.rs | 54 ++-
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/proxmox-tui-installer/
The GUI installer already has the same functionality, with this the TUI
installer gains the same. It is a nice touch anyway, primarily to
indicate to the user that the installer is not frozen or similar.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
proxmox-low-level-insta
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
proxmox-low-level-installer | 45 +++--
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/proxmox-low-level-installer b/proxmox-low-level-installer
index 0f2bf4f..b8269d7 100755
---
First #5 patches splits out the gigantic install progress dialog into its
own module; then applying some divide-and-conquer to make it more
readable and get the inner >150 lines closure down to a more
maintainable state. Purely code movement without any functional changes.
Patch #6 improves the er
The issue arises because firewall depends on qemu-server but qemu-server
depends on SDN. So if I try to include firewall from SDN, it will not work.
I have looked at Firewall for quite some time now. Some functions in
Firewall.pm depend on QemuServer mainly for the parse_net function. I
tried to
While there already is a warning from QEMU proper, that one is not
visible as a task warning and it's not straightforward to make it be
one, because QEMU is started inside a run_fork(). It's also more
future-proof to have the detection explicit on our side and the
documentation can be referenced.
expanding from the two currently existing sentences. In the first one, a
typo VMs -> VM's is fixed. In the second one, "one wants to" is changed
to "you want to", because the sentence already starts with "You can" and
it's active voice.
Adds information about the machine version, rationale behind
Will be used for a warning.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer/Machine.pm | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/PVE/QemuServer/Machine.pm b/PVE/QemuServer/Machine.pm
index c9fc9a3d..13721ae8 100644
--- a/PVE/QemuServer/Machine.pm
+++ b/PVE/Qem
by remembering the 'forcemachine' parameter that's passed along when
starting the target instance.
In preparation to introduce a call to get_current_qemu_machine after
starting a VM to check for machine version deprecation.
Signed-off-by: Fiona Ebner
---
test/MigrationTest/QmMock.pm | 14 ++
by adding a comment and grouping the code better. See the PVE QEMU
patch "PVE: Allow version code in machine type" for reference. The way
the code was written previously made it look like a bug where
$pve_version might be overwritten multiple times.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer/
There are already some deprecated machine versions in QEMU currently,
namely 1.4-1.7 for i440fx and QEMU 8.2 will add some more. At some
point, support for these will be dropped completely, so start
informing and warning users about this.
docs:
Fiona Ebner (1):
qm: add section about machine ty
No functional change intended.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer/Machine.pm | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/PVE/QemuServer/Machine.pm b/PVE/QemuServer/Machine.pm
index d9429ed4..a4bc24a5 100644
--- a/PVE/QemuServer/Machine.pm
+++ b/PVE/Q
No point iterating through the rest if we already got the current
machine.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer/Machine.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuServer/Machine.pm b/PVE/QemuServer/Machine.pm
index 85cfb89c..c9fc9a3d 100644
--- a/PV
Am 10.11.23 um 11:54 schrieb Markus Ebner:
>> But I do have another suggestion too: Should we rather automatically
>> preserve the current volume name (just replacing the VM ID) if there is
>> no other volume with that name and choose a new name if there is? For
>> offline storage migration, we als
Is there anything else missing on my end? The patch still applies.
Maximiliano Sandoval writes:
> Continuation of ab70343982f36a5343d3fcf4a1a6489bd3f52a66. Discussion at
> https://lists.proxmox.com/pipermail/pve-devel/2023-September/059013.html.
>
--
Maximiliano
__
On October 31, 2023 10:05 am, Folke Gleumes wrote:
> Changes since v2:
> * reverted the new_account abi to be non breaking
>
> Changes since v1:
> * fixed nit's
> * expanded meta endpoint by all return values defined in the rfc
> * expanded new_account signature by field for eab credentials
>
On June 14, 2023 11:30 am, Aaron Lauterer wrote:
> For that we need to add a new format option that checks against valid
> VLAN tags and ranges, for example: 2 4 100-200
>
> The check, if the default value should be used, needs to fail not just
> when not defined, but also in case it is an empty s
On June 14, 2023 11:30 am, Aaron Lauterer wrote:
> The new optional bridge_vids field allows to set that property via the
> GUI. Since the backend needs to support it, the field needs to be
> explicitly enabled.
>
> For now, Proxmox VE (PVE) is the use case.
>
> Signed-off-by: Aaron Lauterer
> -
On June 14, 2023 11:30 am, Aaron Lauterer wrote:
> Signed-off-by: Aaron Lauterer
> ---
> no changes since v1
>
> PVE/API2/Network.pm | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
> index 00d964a7..6f4367cb 100644
> --- a/PVE/API2/Network
--- Begin Message ---
> But I do have another suggestion too: Should we rather automatically
> preserve the current volume name (just replacing the VM ID) if there is
> no other volume with that name and choose a new name if there is? For
> offline storage migration, we also do it like that (sans r
On Tue, Nov 07, 2023 at 02:46:42PM +0100, Filip Schauer wrote:
> Add a dev[n] argument to the container config to pass devices through to
> a container. A device can be passed by its path. Additionally the access
> mode, uid and gid can be specified through their respective properties.
>
> Signed-
stop the tooltip show when the there is no text
this could happen for e.g. nodes that should not have a tooltip
Signed-off-by: Dominik Csapak
---
www/manager6/tree/ResourceTree.js | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/www/manager6/tree/ResourceTree.js
b/www/m
it is a bit more verbose than the usage bar
Signed-off-by: Dominik Csapak
---
www/manager6/tree/ResourceTree.js | 6 ++
1 file changed, 6 insertions(+)
diff --git a/www/manager6/tree/ResourceTree.js
b/www/manager6/tree/ResourceTree.js
index ed51ac32..acfa545a 100644
--- a/www/manager6/tree
it shouldn't be called that often, and if we save it, it gets outdated,
e.g. when starting/stopping a guest
Signed-off-by: Dominik Csapak
---
www/manager6/tree/ResourceTree.js | 3 ---
1 file changed, 3 deletions(-)
diff --git a/www/manager6/tree/ResourceTree.js
b/www/manager6/tree/ResourceTre
since there is nowhere to migrate to and we hide the regular migrate
buttons/options too.
Signed-off-by: Dominik Csapak
---
www/manager6/node/CmdMenu.js | 5 +
www/manager6/node/Config.js | 2 ++
2 files changed, 7 insertions(+)
diff --git a/www/manager6/node/CmdMenu.js b/www/manager6/node
Am 10/11/2023 um 10:34 schrieb Dominik Csapak:
>> +value: 'You cannot use the default SPICE
>> clipboard' +
>> +' if the VNC Clipboard is selected',
>
> nit: i'd maybe like an additional sentence here that says
> the user has to install
Am 08.11.23 um 17:52 schrieb Markus Ebner:
> When the move_disk endpoint is used to reassign a disk image from one
> vm to another, the target-filename of the image is typically chosen
> automatically with the known naming schema.
>
> This patch adds the optional parameter target-filename, allowin
adds vendor and product information for SCSI devices to the json schema and
checks in the VM create/update API call if it is possible to add these to QEMU
as a device option
Signed-off-by: Hannes Duerr
---
PVE/API2/Qemu.pm| 12
PVE/QemuServer.pm | 28 +
changes in v2:
- when calling the API to create/update a VM, check whether the devices
are "scsi-hd" or "scsi-cd" devices,where there is the option to add
vendor and product information, if not error out
- change the format in product_fmt and vendor_fmt to a pattern that only
allows 40 characters c
i tested with an ubuntu live iso (which conveniently has the
spice tools already installed and running after booting it)
found a few small nits, but those could be followed or fixed up,
not big blockers imho
aside from those, consider this series:
Reviewed-by: Dominik Csapak
Tested-by: Dominik
a few nits inline:
On 9/21/23 13:47, Markus Frank wrote:
Signed-off-by: Markus Frank
---
www/manager6/qemu/DisplayEdit.js | 8 +++
www/manager6/qemu/Options.js | 89
2 files changed, 97 insertions(+)
diff --git a/www/manager6/qemu/DisplayEdit.js b/www/
Encapsulation of the functionality for determining the scsi device type in a
new function
for reusability and moving the function and its dependencies
to Qemuserver/Drive.qm for a better overview
Signed-off-by: Hannes Duerr
---
PVE/QemuServer.pm | 87 ++---
one nit inline:
On 9/21/23 13:47, Markus Frank wrote:
add option to use the qemu vdagent implementation to enable the VNC
clipboard. When enabled with SPICE the spice-vdagent gets replaced with the QEMU
implementation.
This patch does not solve #1406, but does allow copy and paste with
a runnin
On 11/10/23 09:18, Thomas Lamprecht wrote:
Am 07/11/2023 um 13:46 schrieb Lukas Wagner:
This will be needed for ACL paths for the notification system,
which will get separate namespaces for targets and matchers:
/mapping/notification/targets/
as well as
/mapping/notification/matchers/
Not
Am 07/11/2023 um 13:46 schrieb Lukas Wagner:
> This will be needed for ACL paths for the notification system,
> which will get separate namespaces for targets and matchers:
>
> /mapping/notification/targets/
> as well as
> /mapping/notification/matchers/
Not that it matters much to this supportin
46 matches
Mail list logo
