--- Begin Message ---
pvestatd is checking this every 10 seconds. This check
produces a lot of noise at the iscsi server logging.
Use iscsiadm command to check the sessions status instead
Signed-off-by: Victor Seva
---
src/PVE/Storage/ISCSIPlugin.pm | 28 +---
1 file cha
--- Begin Message ---
> A little bit of analysis of why this is needed and okay would be great to
> have here in the commit message ;)
Thanks for the feedback, Fabian! First time with git-email..
I'm adding details with logs here, and a detailed description of the
issue & solution in the commit.
--- Begin Message ---
When pve-http-server initiates the closure of a TLS session, it does not
send a TLS close notify, resulting in an unexpected EOF error on systems
with recent crypto policies. This can break functionality with other
applications, such as Foreman[0].
This behavior can be observ
Am 24.02.25 um 13:37 schrieb Philipp Giersfeld:
> Signed-off-by: Philipp Giersfeld
> Tested-by: Markus Frank
> ---
>
> no changes since last version
>
> debian/binary-check.remove | 4 ++--
> debian/rules | 6 +++---
> edk2 | 2 +-
> 3 files changed, 6 inse
"form:" by itself doesn't provide much information as a prefix
Am 12.02.25 um 14:02 schrieb Markus Frank:
> Prerequisite for "ui: window: add diskformat option to restore window"
>
> The hide condition is copied from the format selector item in the same
> file.
>
> Signed-off-by: Markus Frank
>
--- Begin Message ---
Hi Thomas,
We have few more questions in addition to those mentioned in the previous email.
1. How to get allocated blocks/sectors from the snapshot of the raw format
virtual disk attached to a running VM (disk present on the block based storage
such as lvm, lvm-thin, et
Hello everyone,
I would need some feedback on a feature that was requested multiple
times by different users over the years. Specifically, many people have
complained that synchronizing Active Directory groups to PVE
partially/mostly fails due to many groups containing spaces by default:
http
[snip]
+impl PerlSectionConfig {
+pub fn add_fabric(&self, new_config: AddFabric) -> Result<(),
anyhow::Error> {
+let fabricid = FabricId::from(new_config.name).to_string();
Could we simplify this method and the ones below by just using the
concrete types (here FabricId)
Am 05.03.25 um 15:18 schrieb Fiona Ebner:
> Am 24.02.25 um 13:37 schrieb Philipp Giersfeld:
>> AMD SEV-SNP boots with a single volatile firmware image OVMF.fd via the
>> -bios option.
>>
>> Currently, an SEV-enabled VM will not boot with an OVMF
>> firmware that was compiled with `SECURE_BOOT_ENABL
Am 24.02.25 um 13:37 schrieb Philipp Giersfeld:
> This patch is for enabling AMD SEV-SNP support.
>
> Where applicable, it extends support for existing SEV(-ES) variables
> to SEV-SNP. This means that it retains no-debug and kernel-hashes
> options, but the no-key-sharing option is removed.
>
> T
Am 24.02.25 um 13:37 schrieb Philipp Giersfeld:
> Convert policy calcucalation to use shift operators and OR operation
Nit: there is a typo here: calcucalation
> instead of binary numbers and addition.
>
> Signed-off-by: Philipp Giersfeld
> Reviewed-by: Daniel Kral
> Tested-by: Markus Frank
Am 24.02.25 um 13:37 schrieb Philipp Giersfeld:
> AMD SEV-SNP boots with a single volatile firmware image OVMF.fd via the
> -bios option.
>
> Currently, an SEV-enabled VM will not boot with an OVMF
> firmware that was compiled with `SECURE_BOOT_ENABLE` [1].
>
> Furthermore, during testing, SEV-en
Am 05.03.25 um 12:06 schrieb Dominik Csapak:
> in our schema for 'vga' the type is optional, so a config like
>
> vga: memory=64
>
> is valid. When checking the type we have to check if the type is defined
> before accessing it.
>
> Signed-off-by: Dominik Csapak
applied, thanks! Added a 'term
Am 12.02.25 um 14:02 schrieb Markus Frank:
> Signed-off-by: Markus Frank
> ---
> src/PVE/Storage/Plugin.pm | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/PVE/Storage/Plugin.pm b/src/PVE/Storage/Plugin.pm
> index 65cf43f..9f21f0b 100644
> --- a/src/PVE/Storage/Plugin.pm
> +++
"window:" by itself doesn't provide much information as a prefix. If you
use "restore window:" then you can drop that from the end of the commit
title.
Am 12.02.25 um 14:02 schrieb Markus Frank:
> @@ -141,9 +144,10 @@ Ext.define('PVE.window.Restore', {
>
> view.lookupRef
Am 12.02.25 um 14:02 schrieb Markus Frank:
> Add an option to choose a file format (qcow2, raw, vmdk) when restoring
> a vm backup to file based storage. This options allows all disks to be
> recreated with the specified file format if supported by the target
> storage.
>
> Signed-off-by: Markus F
v1:
https://lore.proxmox.com/pve-devel/20250207125514.42668-1-f.eb...@proxmox.com/
Changes in v2:
* different approach, use existing format
* introduce standard option
* add patches to drop mythological 'cow' format
Allow using 'vmdk' for the 'format' option when allocating an image
with 'pvesm'
Signed-off-by: Fiona Ebner
---
src/PVE/Storage/Plugin.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/PVE/Storage/Plugin.pm b/src/PVE/Storage/Plugin.pm
index 79f6f08..dfdab16 100644
--- a/src/PVE/Storage/Plugin.pm
+++ b/src/PVE/Storage/Plugin.pm
@@ -346,7 +346,7 @@ PVE:
On Tue Mar 4, 2025 at 4:41 PM CET, Alexander Zeidler wrote:
> * ZFS: Restructure the sentence.
should this be XFS? you restructure a sentence about XFS/ext4 below, but
not ZFS
> * BTRFS: Explain the swap configuration options in a little more detail.
>
> Signed-off-by: Alexander Zeidler
> ---
>
--- Begin Message ---
Hi Dominik,
It is very likely we'll have access to a suitable cluster to test this
before summer, provided these patches are in published packages.
I can test and report back if that's helpful.
Regards
El 20/1/25 a las 15:51, Dominik Csapak escribió:
and some useful cl
in our schema for 'vga' the type is optional, so a config like
vga: memory=64
is valid. When checking the type we have to check if the type is defined
before accessing it.
Signed-off-by: Dominik Csapak
---
PVE/API2/Qemu.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Am 05.03.25 um 10:46 schrieb Fiona Ebner:
> Am 04.03.25 um 19:09 schrieb Thomas Lamprecht:
>> Not a huge fan, but it would be fine for me as long as they are
>> targeted; ensuring upgrade is easy reduces pressure for requiring an
>> LTS.
...
>> Albeit remote migration was/is rather a bit experime
[snip]
+#[derive(Serialize, Deserialize, Debug, Default)]
+pub struct FabricConfig {
+openfabric: Option,
+ospf: Option,
+}
+
+impl FabricConfig {
+pub fn new(raw_openfabric: &str, raw_ospf: &str) -> Result {
+let openfabric =
+openfabric::internal::OpenFabricConfig
The new 'pve-storage-image-format' standard option uses a simple enum
instead of a subroutine verifier. Since the 'pve-storage-format'
format that is replaced by it was used in pve-guest-common's
StorageTunnel, the format cannot be removed without a versioned
breaks.
Signed-off-by: Fiona Ebner
--
Signed-off-by: Fiona Ebner
---
src/PVE/StorageTunnel.pm | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/PVE/StorageTunnel.pm b/src/PVE/StorageTunnel.pm
index c880889..c0cc0ae 100644
--- a/src/PVE/StorageTunnel.pm
+++ b/src/PVE/StorageTunnel.pm
@@ -7,7 +7,9 @@ use I
The format was dropped in QEMU binary version 2.2 with commit
550830f935 ("block: delete cow block driver").
Very old backups might still include this format as a hint (the data
in the backup is present in raw/chunk format in any case), but that is
not an issue. Restore already checks that the tar
Signed-off-by: Fiona Ebner
---
src/PVE/API2/Storage/Content.pm | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/PVE/API2/Storage/Content.pm b/src/PVE/API2/Storage/Content.pm
index fe0ad4a..3b73e90 100644
--- a/src/PVE/API2/Storage/Content.pm
+++ b/src/PVE/API2/Storage/Content.pm
@@ -2,7 +2,
The API endpoint will automatically detect the format from the
extension for raw, qcow2 and vmdk, but it was not yet possible to
specify the format explicitly via the parameter. This could be
annoying/surprising to users. There also might be third-party plugins
that want to use vmdk, but not requir
The format was dropped in QEMU binary version 2.2 with commit
550830f935 ("block: delete cow block driver").
This follows qemu-server commit "drive: remove ancient 'cow' from
formats".
Signed-off-by: Fiona Ebner
---
src/PVE/Storage/Plugin.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Am 04.03.25 um 19:09 schrieb Thomas Lamprecht:
> Am 12.02.25 um 11:55 schrieb Fabian Grünbichler:
>> do we still want to bump this? do we also want to include other recent
>> fixes for remote migration if we do so?
>
> Not a huge fan, but it would be fine for me as long as they are
> targeted; ens
On Tue Mar 4, 2025 at 4:41 PM CET, Alexander Zeidler wrote:
> * Introduce sections and subsections to enable better readability.
> * Move screenshots to their corresponding installation step and add
> blank lines for proper formatting.
>
> Notable changes:
>
> Step 1:
> * Since the EULA is only a
On Tue, Mar 04, 2025 at 06:30:50PM +0100, Gabriel Goller wrote:
> On 28.02.2025 14:57, Thomas Lamprecht wrote:
> > Am 14.02.25 um 14:39 schrieb Gabriel Goller:
> > > This adds the intermediate, type-checked fabrics config. This one is
> > > parsed from the SectionConfig and can be converted into th
On Tue Mar 4, 2025 at 4:40 PM CET, Alexander Zeidler wrote:
> * Describe what the installer does, this was earlier included in the
> installation introduction
> * Mention the importance of a redundant disk setup
> * s/CD-ROM/DVD/
> * Rephrase and expand the boot tip
>
> Signed-off-by: Alexander Z
On Tue Mar 4, 2025 at 4:40 PM CET, Alexander Zeidler wrote:
> * Mention all currently available install options and link to them
> (interactive installer, unattended, on top of Debian)
> * Remove installer details and link to the installer, where the
> information will be included by a subseque
On 25/02/24 01:37PM, Philipp Giersfeld wrote:
> This patch series adds support for AMD SEV-SNP.
> Where possible it mimics the existing support for AMD SEV(-ES).
>
> Running SEV-SNP VMs requires a more recent version of edk2
> and OVMF firmware image. Contrary to other setups, SEV-SNP does not s
On 03.03.2025 16:08, Stefan Hanreich wrote:
Maybe we should think about internally representing the Network Entity
Title and its parts as bytes rather than strings? So [u8; n]? Since in
practice it's exactly that. I think this would simplify a lot of the
methods here, and obsolete some stuff like
36 matches
Mail list logo
