When writing into the file, explicitly utf8 encode it, and then try to
utf8 decode it on read.
If the notes are not valid utf8, we assume it was an iso-8859 comment
and return is at is was.
Technically this is a breaking change, since there are iso-8859 comments
that would sucessfully decode as u
when the vm is stopped and the user clicks on the 'start now' button,
there really is no need for confirmation again
Signed-off-by: Dominik Csapak
---
...ow-start-button-on-not-running-vm-ct.patch | 26 ---
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/debian/pat
sorry i forgot to fix the s/sucessfully/successfully/ typo...
also:
On 3/9/22 09:21, Dominik Csapak wrote:
When writing into the file, explicitly utf8 encode it, and then try to
utf8 decode it on read.
If the notes are not valid utf8, we assume it was an iso-8859 comment
and return is at is was
Upgrading a cluster node entails re-starting or migrating VMs and even
PVE 6.0 already had QEMU 4.0.
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 7 ---
1 file changed, 7 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index b7e6a8e..c0fca49 100644
--- a/PVE/QemuServe
While the new options should be written to the pending config, the
decisions (currently only one) in create_disks needs to be made for
the current config.
Seems to fix EFI disk creation, but actually, it's only
future-proofing, because, currently, the same OVMF_VARS file is
used independently of $
For creation, activation and size update never triggered, because the
passed in $conf is essentially the same as the creation $settings, so
the disk was always detected to be the same as the "existing" one. But
actually, all disks are new, so it makes sense to do it.
For update, activation and siz
to make the interface more digestible.
Signed-off-by: Fabian Ebner
---
PVE/API2/Qemu.pm | 52 +++
PVE/QemuServer.pm | 9 ++--
2 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index c6587ef..14ca
Signed-off-by: Dominic Jäger
[split into its own patch + style fixes]
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index b246602..33f226e 100644
--- a/PVE/QemuServer.pm
Prepare for calling parse_ovf via API, where the -T switch is used.
Signed-off-by: Fabian Ebner
---
PVE/QemuServer/OVF.pm | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/PVE/QemuServer/OVF.pm b/PVE/QemuServer/OVF.pm
index 0376cbf..b97b052 100644
--- a/PVE/QemuServer/
In the spirit of c75bf16 ("qm importdisk: tell user to what VM disk we
actually imported"), and so that the information is not lost once qm
importdisk switches to re-using the API call.
Added for cloudinit too, because a new disk is allocated.
Signed-off-by: Fabian Ebner
---
The name for cloudi
It's confusing that the config associated to the destination is
actually a reference to the source config for both existing callers.
Also, disk import will need to base the calculation on the passed-in
drive parameters and not just the current config, so this change is in
preparation for that too.
Because the paths under /nodes/{node}/qemu/ are already occupied by
a {vmid} regex, it's not possible to use /nodes/{node}/qemu/readovf
for the new call. As the call does not depend upon a particular vmid,
it's placed under /nodes/{node} instead.
Signed-off-by: Dominic Jäger
[split into its own p
Co-developed-by: Fabian Grünbichler
Signed-off-by: Dominic Jäger
[split into its own patch + minor improvements/style fixes]
Signed-off-by: Fabian Ebner
---
PVE/API2/Qemu/Makefile | 2 +-
PVE/API2/Qemu/OVF.pm | 55 ++
PVE/QemuServer.pm | 32 ++
and also when source and target drivename are different. In those
cases, it is done via qemu-img convert/dd.
In preparation to allow import from existing PVE-managed disks.
Signed-off-by: Fabian Ebner
---
PVE/API2/Qemu.pm | 2 ++
PVE/QemuServer.pm | 29 +++--
2 files c
Avoids the error
adding drive failed: Duplicate ID 'drive-scsi1' for drive
that could happen when switching over to a new disk (e.g. via qm set),
if unplugging wasn't fast enough.
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/QemuServ
via the special syntax :.
Not worth it by itself, but this is anticipating a new 'import-from'
parameter which is only used upon import/allocation, but shouldn't be
part of the schema for the config or other API enpoints.
Signed-off-by: Fabian Ebner
---
PVE/API2/Qemu.pm| 12 ++--
PV
For disk import, it should be based on the disk properties that are
passed in rather than on those of a possibly pre-existing disk in the
config.
Signed-off-by: Fabian Ebner
---
New in v12.
PVE/QemuServer.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/PVE/QemuServe
Necessary to import from an existing storage using block-device
volumes like ZFS.
Signed-off-by: Dominic Jäger
[split into its own patch]
Signed-off-by: Fabian Ebner
---
PVE/QemuServer.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
i
Extend qm importdisk/importovf functionality to the API.
Changes from v11 (after an off-list discussion with Fabian G.):
* Avoid confusing $dest->{conf} parameter for clone_disk().
* Require relevant parameters to be set explicitly for EFI/TPM.
* Base calculation of EFI vars size on pa
Signed-off-by: Fabian Ebner
---
PVE/API2/Qemu.pm | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 3b86034..7c3bb91 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -63,6 +63,23 @@ my $reso
From: Dominic Jäger
Extend qm importdisk functionality to the API.
Co-authored-by: Fabian Grünbichler
Co-authored-by: Dominic Jäger
Signed-off-by: Fabian Ebner
---
Changes from v11:
* Require relevant parameters to be set explicitly for EFI/TPM
disk import.
* Base calculation o
Am 04.03.22 um 12:52 schrieb Matthias Heiserer:
> Signed-off-by: Matthias Heiserer
> ---
Some rationale for the change would be nice to have in the commit
message. Is there a scenario where me.pveSelNode is not the correct node?
> www/manager6/window/BackupConfig.js | 2 +-
> 1 file changed, 1
Am 04.03.22 um 12:52 schrieb Matthias Heiserer:
> Signed-off-by: Matthias Heiserer
> ---
> www/manager6/Utils.js | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js
> index aafe359a..6509 100644
> --- a/www/manager6/Uti
Am 04.03.22 um 12:52 schrieb Matthias Heiserer:
> Should be easier to read/use than the current flat list.
> Backups are grouped by ID and type, so in case there are backups
> with ID 100 for both CT and VM, this would create two separate
> groups in the UI.
It might make sense to include qemu/lxc
--- Begin Message ---
Hi,
Ok. Funny enough, I suffered from this issue last night during maintenance… But
since I have not had this issue before, I had no snapshot…
I guess the snapshot would need to have a state as well, right? So the machine
is ‘booted’ as it was.
—
Mark Schouten, CTO
Tuxis
the 'value' here is already the rendered text, passing it through
render again does not make sense
Signed-off-by: Dominik Csapak
---
www/manager6/Utils.js | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js
index aafe359a..d6aeaf3
Previously, deselecting and reselecting the input field
led to the previous filter still being applied, although the
input field was cleared.
Signed-off-by: Matthias Heiserer
---
src/form/ComboGrid.js | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/form/ComboGrid.js b/src/form/ComboGrid.
When clicking on a column to sort it, the filter doesn't reset.
Previously, it forgot the filter until the value was changed.
Signed-off-by: Matthias Heiserer
---
src/form/ComboGrid.js | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/form/ComboGrid.js b/src/form/ComboGrid.js
index
Am 09.03.22 um 14:38 schrieb Mark Schouten:
> Hi,
>
> Ok. Funny enough, I suffered from this issue last night during maintenance…
> But since I have not had this issue before, I had no snapshot…
>
> I guess the snapshot would need to have a state as well, right? So the
> machine is ‘booted’ as
Ping for the series. Or do we not want the limit after all (as far as
I'm aware, nobody complained yet)?
Am 16.12.21 um 13:12 schrieb Fabian Ebner:
> The series consists of two parts:
>
> First part (up to docs 2/2) is for introducing a storage property
> to limit the number of protected backups
Ping
Am 30.11.21 um 11:38 schrieb Fabian Ebner:
> to avoid a "malformed JSON string" warning when there is no old
> version present (e.g. after starting a cluster).
>
> get_node_kv will always return something that evaluates to true, so
> instead, test if the result has an entry for the current n
31 matches
Mail list logo