On 2/19/20 5:10 PM, Wolfgang Bumiller wrote:
> On Tue, Feb 18, 2020 at 02:38:52PM +0100, Oguz Bektas wrote:
>> 'stop' mode deactivates the volumes (relevant for LVM backend), and
>> they're not reactivated before trying to mount them for backup.
>>
>> reactivating the volumes before the mount in 'stop' mode backup solves
>> the issue.
>>
>> Signed-off-by: Oguz Bektas <o.bek...@proxmox.com>
>
> Acked-by: Wolfgang Bumiller <w.bumil...@proxmox.com>
>
with that applied, thanks to both!
>> ---
>> src/PVE/VZDump/LXC.pm | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/src/PVE/VZDump/LXC.pm b/src/PVE/VZDump/LXC.pm
>> index 0260184..ed6daa2 100644
>> --- a/src/PVE/VZDump/LXC.pm
>> +++ b/src/PVE/VZDump/LXC.pm
>> @@ -310,6 +310,7 @@ sub archive {
>> if ($task->{mode} eq 'stop') {
>> my $rootdir = $default_mount_point;
>> my $storage_cfg = $self->{storecfg};
>> + PVE::Storage::activate_volumes($storage_cfg, $task->{volids});
>
> This we definitely need. Additionally, we can consider removing this
> from prepare().
followed up with that.
> Do we maybe also want a 'skip-deactivate' flag for the
> vm-stop call made from vzdump?
I mean, would be OK, but no hard feelings - for most this doesn't do anything
at all, not sure how much load a lvm deactivate/activate cycle puts on the
system - if unnecessary IO can be avoided, why not..
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
