[pve-devel] [PATCH v2 pve-manager 20/22] PVE::Replication - aquire guest_migration_lock during replication

[Fabian Grünbichler]

On Mon, May 29, 2017 at 11:30:04AM +0200, Dietmar Maurer wrote:
> To block guest migration.
> 
> Signed-off-by: Dietmar Maurer <dietmar at proxmox.com>
> ---
>  PVE/Replication.pm | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/PVE/Replication.pm b/PVE/Replication.pm
> index a3bbc322..3f1072d0 100644
> --- a/PVE/Replication.pm
> +++ b/PVE/Replication.pm
> @@ -11,6 +11,7 @@ use PVE::ProcFSTools;
>  use PVE::Tools;
>  use PVE::CalendarEvent;
>  use PVE::Cluster;
> +use PVE::AbstractConfig;
>  use PVE::QemuConfig;
>  use PVE::QemuServer;
>  use PVE::LXC::Config;
> @@ -388,7 +389,12 @@ my $run_replication = sub {
>  
>      $logfunc->($start_time, "$jobcfg->{id}: start replication job") if $logfunc;
>  
> -    eval { replicate($jobcfg, $state->{last_sync}, $start_time, $logfunc); };
> +    eval {
> +	my $timeout = 2; # do not wait too long - we repeat periodically anyways
> +	PVE::AbstractConfig::guest_migration_lock(

shouldn't this be QemuConfig/LXC::Config->migration_lock instead?

we don't have any direct calls to AbstractConfig anywhere in our code
base, and we already have the vmtype in the jobcfg anyway.

if you don't want to add another if / else, we could store a reference
to the config class in $jobcfg? then we could just use that directly
wherever we need it.

> +	    $jobcfg->{guest}, $timeout, \&replicate,
> +	    $jobcfg, $state->{last_sync}, $start_time, $logfunc);
> +    };
>      my $err = $@;
>  
>      $state->{duration} = tv_interval($t0);
> -- 
> 2.11.0
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel