Thomas Lamprecht [Fri, 18 Oct 2019 14:43:25 +0000 (16:43 +0200)]
refactor parse_pending_delete to sane implemenation
this was quite the mess, a perl greedy match over non-whitespace
character is equivalent to a split on whitespace on, but the latter
is much easier to grasp when looking at this the first time.
Do a real for loop with real variable names and less nest everything
into one line.
the test added in the previous commit should give use the safety net
for that cleanup.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Oguz Bektas [Mon, 14 Oct 2019 08:28:34 +0000 (10:28 +0200)]
abstractconfig: add load_current_config and load_snapshot_config
this code is already used by qemu-server's GET config API call. it is
however better to split this into to methods and decide what to run in
the API call.
this general implementation uses some $class helpers which allow to abstract
away the difference in the child classes. this will be used for
containers once they can do pending changes.
parse_pending_delete now has a better representation of the force value,
which is encoded in a perl hash i.e. $conf->{$opt}->{force} = 1 or 0
depending on if the string in config has '!' or not.
Christian Ebner [Tue, 15 Oct 2019 11:00:19 +0000 (13:00 +0200)]
vzdump: move registration of vzdump.cron from manager to guest-common to avoid cyclic dependency
The registration of the vzdump.cron file was handled in pve-manager.
By moving the relevant code to pve-guest-common, cyclic dependencies
for cfs registration are avoided.
This makes this patch of guest-common a build dependency for the other
packages touched in this patch series.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
followup: rename to print_snapshot_tree, add comment and rename $res param
This was taken from a CLI helper, there $res is a common parameter
name which denotes that it's the res from the API call the CLI
command bases on. But here that makes no sense and is not really
telling about what the value(s) of $res could be. Further explain
that with a comment.
As this also prints uncoditionally to STDOUT let's say so through the
method name.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Oguz Bektas [Tue, 1 Oct 2019 07:32:45 +0000 (09:32 +0200)]
reformat code for snapshot tree into GuestHelpers
qm/pct listsnapshot lack feature parity w.r.t. showing snapshots in a
tree ordered by the date. by moving this code into GuestHelpers, it can
be shared.
Thomas Lamprecht [Tue, 21 May 2019 19:00:28 +0000 (21:00 +0200)]
buildsys: use dpkg-dev makefile helpers for pkg info
while we already dynamically resolved the version from the changelog
using dpkg-parsechangelog, and those dpkg-dev helpers also use that
tool, let's switch to them nonetheless to have a bit more stream
lined dev environment.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Wolfgang Link [Wed, 9 May 2018 12:48:24 +0000 (14:48 +0200)]
Get snapshots when no state is available.
With this patch we can restore the state of a state less job.
It may happen that there are more replication snapshots,
because no job state is known can not delete any snapshot.
Existing multiple replication-snapshot happens
when a node fails in middel of a replication
and then the VM is moved to another node.
That's why we have to test if we have a common base on both nodes.
Given this, we take this as a replica state.
After we have a state again, the rest of the snapshots can be deleted on the next run.
Wolfgang Link [Wed, 9 May 2018 12:48:23 +0000 (14:48 +0200)]
Delete replication snapshots only if last_sync is not 0.
If last_sync is 0, the VM configuration has been stolen
(either manually or by HA restoration).
Under this condition, the replication snapshot should not be deleted.
This snapshot is used to restore replication state.
If the last_snap is greater than 0 and does not match the snap name
it must be a remnant of an earlier sync and should be deleted.
Wolfgang Link [Wed, 9 May 2018 12:48:21 +0000 (14:48 +0200)]
Cleanup for stateless jobs.
If a VM configuration has been manually moved or recovered by HA,
there is no status on this new node.
In this case, the replication snapshots still exist on the remote side.
It must be possible to remove a job without status,
otherwise, a new replication job on the same remote node will fail
and the disks will have to be manually removed.
When searching through the sorted_volumes generated from the VMID.conf,
we can be sure that every disk will be removed in the event
of a complete job removal on the remote side.
In the end, the remote_prepare_local_job calls on the remote side a prepare.
Wolfgang Link [Fri, 13 Apr 2018 10:24:39 +0000 (12:24 +0200)]
fix #1694: make failure of snapshot removal non-fatal
In certain high-load scenarios ANY ZFS operation can block,
including registering an (async) destroy.
Since ZFS operations are implemented via ioctl's,
killing the user space process
does not affect the waiting kernel thread processing the ioctl.
Once "zfs destroy" has been called, killing it does not say anything
about whether the destroy operation will be aborted or not.
Since running into a timeout effectively means killing it,
we don't know whether the snapshot exists afterwards or not.
We also don't know how long it takes for ZFS to catch up on pending ioctls.
Given the above problem, we must to not die on errors when deleting a no
longer needed snapshot fails (under a timeout) after an otherwise
successful replication. Since we retry on the next run anyway, this is
not problematic.
The snapshot deletion error will be logged in the replication log
and the syslog/journal.
Thomas Lamprecht [Thu, 14 Dec 2017 06:58:36 +0000 (07:58 +0100)]
vzdump: add common log sub-method
Add a general log method here which supports to pass on the "log to
syslog too" functionality and makes it more clear what each
parameter of logerr and logginfo means.
Further, we can now also log wlith a 'warn' level, which can be
useful to notice an backup user of a possible problem which isn't a
error per se, but may need the users attention.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Wed, 13 Sep 2017 08:30:14 +0000 (10:30 +0200)]
VZDump/Plugin: avoid cyclic dependency
pve-guest-common is above qemu-server, pve-container and thus also
pve-manager in the package hierarchy.
The latter hosts PVE::VZDump, so using it here adds a cyclic
dependency between pve-manager and pve-guest-common.
Move the log method to the base plugin class and inline the
run_command function directly do the plugins cmd method.
pve-manager's PVE::VZDump may use this plugins static log function
then instead of its own copy.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
AbstractMigrate: do not overwrite global signal handlers
perls 'local' must be either used in front of each $SIG{...}
assignments or they must be put in a list, else it affects only the
first variable and the rest are *not* in local context.
This may cause weird behaviour where daemons seemingly do not get
terminating signals delivered correctly and thus may not shutdown
gracefully anymore.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
projects / pve-guest-common.git / log