Sorry, I didn't prefix the other reply with a comment. Anyway, everything was
pretty much fine, I just had some little issues. With this, I have some even
more minor issues.
> On 15.01.2021 14:17 Alwin Antreich mailto:a.antre...@proxmox.com > wrote:
>
>
> Signed-off-by: Alwin Antreich
> On 15.01.2021 14:17 Alwin Antreich mailto:a.antre...@proxmox.com > wrote:
>
>
> Signed-off-by: Alwin Antreich mailto:a.antre...@proxmox.com >
> ---
> pveceph.adoc | 45 ++---
> 1 file changed, 38 insertions(+), 7 deletions(-)
>
>
Signed-off-by: Alwin Antreich
---
pveceph.adoc | 45 ++---
1 file changed, 38 insertions(+), 7 deletions(-)
diff --git a/pveceph.adoc b/pveceph.adoc
index fd3fded..42dfb02 100644
--- a/pveceph.adoc
+++ b/pveceph.adoc
@@ -466,12 +466,16 @@ WARNING: **Do not
Signed-off-by: Alwin Antreich
---
pveceph.adoc | 36
1 file changed, 36 insertions(+)
diff --git a/pveceph.adoc b/pveceph.adoc
index 42dfb02..da8d35e 100644
--- a/pveceph.adoc
+++ b/pveceph.adoc
@@ -540,6 +540,42 @@ pveceph pool destroy
NOTE: Deleting the d
Signed-off-by: Fabian Ebner
---
Stumbled upon this, cannot hurt to have an explicit reminder IMHO
PVE/VZDump/Common.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/VZDump/Common.pm b/PVE/VZDump/Common.pm
index 389473b..0391706 100644
--- a/PVE/VZDump/Common.pm
+++ b/PVE/VZDump/Common
When a job is updated, verify_vzdump_parameters() is called twice. This led to
parse_property_string being called with the already parsed option.
Reported on the pve-user mailing list:
https://lists.proxmox.com/pipermail/pve-user/2021-January/172258.html
Signed-off-by: Fabian Ebner
---
The foll
On clone_vm when cloning the disks while the VM is running, we use
drive-mirror. We skip completion until the last disk, but with a
cloudinit disk there's no drive-mirror and so no completion done. If it
is the last disk in the hash, we never complete the drive-mirror jobs
and no further cloning is
I have sent another patch,
with a config option
(Like this, user can define behaviour)
Le jeudi 14 janvier 2021 à 16:20 +0100, aderum...@odiso.com a écrit :
> > > We could add vendor data and put the ssh keys there:
> > > >
> > > > https://cloudinit.readthedocs.io/en/latest/topics/vendordata.htm
and squash the __no_lock-variant into it.
This lock is not broad enough, because for a caller that plans to do or not do
some storage operation based on the result of the check, the following could
happen:
1. volume_is_base_and_used is called and the result is used to enter a branch
2. situation o