On February 11, 2021 11:32 am, Dominic Jäger wrote:
> Thank you for looking so carefully!
>
> On Wed, Feb 10, 2021 at 10:40:56AM +0100, Fabian Grünbichler wrote:
>>
>> On February 5, 2021 11:04 am, Dominic Jäger wrote:
>> > Extend qm importdisk/importovf functionality to the API.
>> >
>> > @@ -
On Fri, Feb 12, 2021 at 10:03:50AM +0100, Fabian Grünbichler wrote:
> >> > +my $store_conf = PVE::Storage::config();
> >>
> >> it probably makes sense to pass this in as parameter, all call sites
> >> probably have it already ;)
> >
> > I just noticed that I have it in importdisk, but unused
to make it more compatible to what we had previously. In pve-manger,
split_list() is called on the parameter, so any whitespaces and even stand-alone
',' and ';' are taken care of, leaving only the real addresses. This also fixes
creating a backup job with empty mailto in the UI.
For example,
> vz
as it now also includes tests for new() with non-retention options.
Signed-off-by: Fabian Ebner
---
test/Makefile | 8
test/{vzdump_new_retention_test.pl => vzdump_new_test.pl} | 0
2 files changed, 4 insertions(+), 4 deletions(-)
rename test
Re-use the existing code, by allowing special kinds of "tests" that just set
the options that are tested for.
Signed-off-by: Fabian Ebner
---
Patch #1 and thus a dependency bump on guest-common are needed
test/vzdump_new_retention_test.pl | 174 +-
1 file changed, 1
so it can be mocked.
Signed-off-by: Fabian Ebner
---
PVE/API2/VZDump.pm | 11 +--
PVE/VZDump.pm | 21 +
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/PVE/API2/VZDump.pm b/PVE/API2/VZDump.pm
index 806ac7fd..44376106 100644
--- a/PVE/API2/VZDump.
On 11.02.21 17:11, Stefan Reiter wrote:
> Signed-off-by: Stefan Reiter
> ---
>
> Rebased from Fabian's series. Thus of course also needs the updated version of
> libproxmox-backup-qemu to build and run.
>
> See: https://lists.proxmox.com/pipermail/pve-devel/2021-February/046945.html
>
> .../pv
On 11.02.21 17:11, Stefan Reiter wrote:
> Lots of patches touched and some slight changes to the build process
> since QEMU switched to meson as their build system. Functionality-wise
> very little rebasing required.
>
> New patches introduced:
> * pve/0058: to fix VMA backups and clean up some co
On 09.02.21 12:29, Fabian Grünbichler wrote:
> for easier auto-generation of versioned deps. when adding new symbols,
> the build should display a warning + diff (in addition to our manual
> tracking of the generated header file). changes in symbol signatures or
> semantics are not caught automatic
On 09.02.21 12:29, Fabian Grünbichler wrote:
> it ships a symbol file now, so it can be auto-generated based on the
> build-dep and usage.
>
> Signed-off-by: Fabian Grünbichler
> ---
> WARNING: this needs a version of libproxmox-backup-qemu0 with symbols
> files in the build deps, otherwise the g
On 08.02.21 14:08, Fabian Grünbichler wrote:
> this is a breaking change/API extension.
>
> Signed-off-by: Fabian Grünbichler
> ---
>
> Notes:
> requires appropriate Breaks on old pve-qemu-kvm, and versioned build and
> runtime dep from pve-qemu-kvm on bumped libproxmox-backup-qemu.
>
we always have to calculate the url correctly, not only on creation
otherwise we try to edit the token by doing a 'PUT' request on
/access/users
and not on
/access/users/USERID/token/TOKENID
Signed-off-by: Dominik Csapak
---
www/manager6/dc/TokenEdit.js | 15 +++
1 file changed, 7 in
Signed-off-by: Aaron Lauterer
---
v2: moved all lines of the parameter call to their separate lines after
the call
www/manager6/qemu/HardwareView.js | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/www/manager6/qemu/HardwareView.js
b/www/manager6/qemu/HardwareView.js
ind
Signed-off-by: Aaron Lauterer
---
v2: use template strings
www/manager6/qemu/HardwareView.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/www/manager6/qemu/HardwareView.js
b/www/manager6/qemu/HardwareView.js
index 3c4ce821..730a44d9 100644
--- a/www/manager6/qemu/Hardwar
There are several types of drives that use the same config keys. Most
notably CDRom and regular VM disks (EFI and cloudinit exist as well).
Since there is a dedicated permission for CDRom drives we need to check
permissions in more detail, depending on what type of drive it actually
is for things
Since CDRoms and disks share the same config keys, we need to check if
it actually is a CDRom and then check the permissions accordingly.
Otherwise it is possible for someone without VM.Config.CDROM
permissions, but with VM.Config.Disk permissions to remove a CD drive
while being unable to create
By removing global vars 'i' and 'confid' and declaring them with let in the
needed
context.
'i' wasn't necessary but had to be touched anyway.
Signed-off-by: Aaron Lauterer
---
v2: removed the global definitions for i and confid and declared them
locally where needed.
www/manager6/qemu/Hardw
Signed-off-by: Stoiko Ivanov
---
did a quick test on my zfs storage-replication testcluster:
* both systems failed to import their zfs pools upon boot (I'm quite sure
it's related to upstream commit 642d86af0d91b2bf88d5ea34cb6888b03c39c459)
* both systems were used for running the zfs testsuite
18 matches
Mail list logo
