On 3/6/24 15:04, Fiona Ebner wrote:
Yes, but the question is what is worse: Needing to re-do the clone or
having the VM config on the wrong node?
To avoid that, I'd lean towards keeping the behavior of failing the task
if deactivating $newvollist fails. After all, at least in case of LVM
not
Am 06.03.24 um 14:14 schrieb Friedrich Weber:
> On 06/03/2024 13:40, Fiona Ebner wrote:
>> Am 06.03.24 um 11:47 schrieb Hannes Duerr:
>>> @@ -3820,7 +3821,13 @@ __PACKAGE__->register_method({
>>>
>>> if ($target) {
>>> # always deactivate volumes - avoid lvm LVs to be
On 06/03/2024 13:40, Fiona Ebner wrote:
> Am 06.03.24 um 11:47 schrieb Hannes Duerr:
>> @@ -3820,7 +3821,13 @@ __PACKAGE__->register_method({
>>
>> if ($target) {
>> # always deactivate volumes - avoid lvm LVs to be active on
>> several nodes
>> -PVE
Am 06.03.24 um 11:47 schrieb Hannes Duerr:
> @@ -3820,7 +3821,13 @@ __PACKAGE__->register_method({
>
> if ($target) {
> # always deactivate volumes - avoid lvm LVs to be active on
> several nodes
> - PVE::Storage::deactivate_volumes($storecfg, $vol
Am 06.03.24 um 12:37 schrieb Friedrich Weber:
> Thanks for tackling this! Can confirm this patch demotes the error to a
> warning and lets the qmclone task succeed (with a warning). GUI shows
> "Warnings: 1" and task log contains:
>
> can't deactivate LV '/dev/foobar/vm-100-disk-0': Logical volu
Thanks for tackling this! Can confirm this patch demotes the error to a
warning and lets the qmclone task succeed (with a warning). GUI shows
"Warnings: 1" and task log contains:
can't deactivate LV '/dev/foobar/vm-100-disk-0': Logical volume
foobar/vm-100-disk-0 in use.
WARN: volume deactivatio
When a template with disks on LVM is cloned to another node, the storage
is first activated, then cloned and deactivated again after cloning.
However, if clones of this template are now created in parellel to other
nodes, it can happen that one of the tasks can no longer deactivate the
logical vol
