19 patches for this seems to be too much. Maybe we can try to cleanup the qemu
code for those checks and send those patches upstream (In order to make this
series shorter)?
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.c
--- Begin Message ---
*TL;DR *
*The tar extraction exclude pattern for LXC containers in the source file *
*/usr/share/perl5/PVE/LXC/**Create.pm* *must be changed from './dev/*' to
'dev/*'*
*Steps to reproduce error due to current bug:*
1. Grab any of the root filesystem cloud images from
https://
In QEMU commit a35f8577a0 ("include/hw: add macros for deprecation &
removal of versioned machines"), a new machine version deprecation and
removal policy was introduced. After only 3 years a machine version
will be deprecated while being removed after 6 years.
The deprecation is a bit early consi
Signed-off-by: Fiona Ebner
---
PVE/QemuServer/Machine.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/QemuServer/Machine.pm b/PVE/QemuServer/Machine.pm
index cf00da6d..9b18cf6e 100644
--- a/PVE/QemuServer/Machine.pm
+++ b/PVE/QemuServer/Machine.pm
@@ -269,6 +269,7 @@ sub check_and_pin_
Like this, it can be used by modules that cannot depend on
QemuServer.pm without creating a cyclic dependency.
Signed-off-by: Fiona Ebner
---
PVE/API2/Qemu.pm | 3 ++-
PVE/QemuServer.pm | 42 +++---
PVE/QemuServer/Makefile| 1 +
PVE/QemuServer
Signed-off-by: Fiona Ebner
---
PVE/QemuServer.pm | 9 +
PVE/QemuServer/Machine.pm | 7 +++
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 85bbb38f..5b1ad3bc 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -3
Signed-off-by: Fiona Ebner
---
PVE/API2/Qemu.pm | 3 ++-
PVE/QemuServer.pm | 24 +---
PVE/QemuServer/Machine.pm | 20
3 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 4c8b2bc0..528
Starting from QEMU 9.1, pin to the creation version instead. Support
for machine version 5.1 is expected to drop with QEMU 11.1 and it
would still be good to handle Windows VMs that do not have explicit
machine version for whatever reason. For example, explicitly setting
the machine without a versi
Signed-off-by: Fiona Ebner
---
PVE/API2/Qemu.pm | 4 ++--
PVE/QemuServer.pm | 2 +-
PVE/QemuServer/Machine.pm | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index c7f45051..dc46e2e0 100644
--- a/PVE/API2/Qemu.pm
+++ b/PV
In commit a35f8577a0 ("include/hw: add macros for deprecation &
removal of versioned machines"), a new machine version deprecation and
removal policy was introduced. After only 3 years a machine version
will be deprecated while being removed after 6 years.
The deprecation is a bit early considerin
Signed-off-by: Fiona Ebner
---
PVE/API2/Qemu.pm | 2 +-
PVE/QemuServer.pm | 38 ++
PVE/QemuServer/Machine.pm | 34 ++
3 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/
Signed-off-by: Fiona Ebner
---
PVE/QemuServer/Helpers.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/PVE/QemuServer/Helpers.pm b/PVE/QemuServer/Helpers.pm
index d58bad2b..be10a92a 100644
--- a/PVE/QemuServer/Helpers.pm
+++ b/PVE/QemuServer/Helpers.pm
@@ -19,7 +19,7 @@
Elaborate on new QEMU machine version removal policy and how PVE will
support machine versions. Make sure to also mention the years, so that
users immediately have a good idea for how long it will be.
Signed-off-by: Fiona Ebner
---
qm.adoc | 26 ++
1 file changed, 26 inse
Add an export, since the function is rather commonly used (in
particular inlined in function calls, where prefixing with the module
name would hurt readability) and there won't be much potential for
confusion name-wise.
This was the only user of stat(), so remove the File::stat include.
Signed-of
Suggested by perlcritic.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer/Machine.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/QemuServer/Machine.pm b/PVE/QemuServer/Machine.pm
index 79be4a0e..3b9c826e 100644
--- a/PVE/QemuServer/Machine.pm
+++ b/PVE/QemuServer/Machine
Signed-off-by: Fiona Ebner
---
PVE/API2/Qemu.pm | 4 ++--
PVE/QemuServer.pm | 13 -
PVE/QemuServer/Helpers.pm | 5 +
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 41ad1cb6..4c8b2bc0 100644
--- a/PVE/AP
During virtual machine creation, the machine version is pinned when
the guest OS is Windows. The same should be done when the guest OS
type is newly set to Windows for consistency.
Signed-off-by: Fiona Ebner
---
RFC because it is rather auto-magic-y, so not fully sure we want it.
PVE/API2/Qemu
The old name does not make it clear what exactly the function does.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer.pm | 4 ++--
PVE/QemuServer/Machine.pm | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 12e5543d..5e577431 1
Extract the logic for guest OS-type dependent machine version pinning
into a dedicated helper, so it can be re-used.
Signed-off-by: Fiona Ebner
---
PVE/API2/Qemu.pm | 14 +++---
PVE/QemuServer/Machine.pm | 16
2 files changed, 19 insertions(+), 11 deletions(-)
In QEMU commit a35f8577a0 ("include/hw: add macros for deprecation &
removal of versioned machines"), a new machine version deprecation and
removal policy was introduced. After only 3 years a machine version
will be deprecated while being removed after 6 years.
The deprecation is a bit early consi
There are already other places where 'aarch64' and 'x86_64' are
checked to be the only valid architectures, for example, the
get_command_for_arch() helper, so the new error scenario for an
unknown arch should not cause any regressions.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer.pm |
Cannot use the is_native_arch() helper inside the function anymore,
to avoid a cyclic dependency between the 'CPUConfig' and 'Helpers'
modules, inline it.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer.pm | 19 +++
PVE/QemuServer/Helpers.pm | 13 +
2 files chan
Thank you for the detailed answer and sketching out the plans for the
transition to Rust and when perlmod should be used. That clarifies a lot
for me!
Just wanted to ask about more details for the qemu-server example. Let's
say we get to a point where it is nicely split up into dedicated modules
a
On 03/01/2025 10:49, Fiona Ebner wrote:
> Am 02.01.25 um 16:54 schrieb Max Carrara:
> That is a good point. I agree this is also worth discussing. Do we want
> to put all bindings for PVE there or do we want to have multiple
> libraries for binding? Moving forward, more and more Perl packages will
Am 02.01.25 um 16:54 schrieb Max Carrara:
> On Thu Jan 2, 2025 at 2:53 PM CET, Fiona Ebner wrote:
>> Am 02.01.25 um 14:46 schrieb Fiona Ebner:
>>> Am 20.12.24 um 19:51 schrieb Max Carrara:
Introduce and Package PVE::Path & PVE::Filesystem - v2
=
25 matches
Mail list logo
