[pve-devel] Storage migration: No on-line migration support

[Michael Rasmussen]

I was not aware of the pause command. I will try using that command 
instead of savevm-start/end.

The reason for a possible requirement to freeze the vm is cause by the 
fact that you could have continues writes to the disk which is migrated 
in which case, since writes locally obviously must be faster than writes 
remote, the temporary backend will never be completely flushed. I have 
tested it doing the following while migrating:

ping some_ip > /disk/under/migrate/ping.dump

if the host is not freezed for a couple of seconds the migration will 
never finish since temporary storage will never be empty. Consider the 
temporary storage like a queue. Then the algorithm is as follows:

while queue not empty:
    write old storage;
    stream writes to new storage;
    send commit ok to file system

flush cache where remote storage resides;
shift storage pointer from old to new;
remove queue;

On 01-17-2013 09:24, Alexandre DERUMIER wrote:
> I'm looking to your drive-mirror code,
>
> about
> # if writes to disk occurs the disk needs to be freezed
> # to be able to complete the migration
>
> Are you sure that drive-mirror cannot handle new writes during the 
> mirroring ?
> I think they must be a bitmap a new writes somewhere, maybe it's
> exist some kind of delta write command ?
>
> also, If you really need to freeze the vm, I think you can simply
> pause the vm, you don't need to use savevm-start/end.(because this is
> used to save vm memory)
>
>
>
>
>
> 	my $freeze = sub {
> 		print "Freezing to complete migration...\n";
> 		PVE::QemuServer::vm_mon_cmd($vmid, "savevm-start");
> 	};
>
> 	my $activate = sub {
> 		print "Reactivate after freeze...\n";
> 		PVE::QemuServer::vm_mon_cmd($vmid, "savevm-end");
> 	};
>
> 	eval {
> 		while (1) {
> 			my $stats = PVE::QemuServer::vm_mon_cmd($vmid, 
> "query-block-jobs");
> 			my $stat = @$stats[0];
> 			die "error job is not mirroring" if $stat->{type} ne "mirror";
> 			print $stat->{offset}."/".$stat->{len}."\n";
> 			last if ($stat->{len} == $stat->{offset});
> 			if ($old_len == $stat->{offset}) {
> 				if ($count > 5) {
> 					# if writes to disk occurs the disk needs to be freezed
> 					# to be able to complete the migration
> 					&$freeze;
> 					$count = 0;
> 					$frozen = 1;
> 				} else {
> 					$count++ unless $frozen;
> 				}
> 			}
> 			elsif ($frozen) {
> 				&$activate;
> 				$count = 0;
> 			}
>
> 			$old_len = $stat->{offset};
> 			sleep 1;
> 		}
> 	};
>
>
> ----- Mail original -----
>
> De: "Michael Rasmussen" <mir at datanom.net>
> À: "Alexandre DERUMIER" <aderumier at odiso.com>
> Envoyé: Mardi 15 Janvier 2013 07:49:35
> Objet: Re: [pve-devel] Storage migration: No on-line migration 
> support
>
> On Tue, 15 Jan 2013 07:12:26 +0100 (CET)
> Alexandre DERUMIER <aderumier at odiso.com> wrote:
>
>>
>> Are you sure you completly loose the socket ? Or does it hang 
>> temporarly ?
>>
> It is completely lost. What triggers it is if some command is timed
> out then the next call will generate a lost socket error. This 
> handles
> every time a command times out after 30 sec.
>
> --
> Hilsen/Regards
> Michael Rasmussen
>
> Get my public GnuPG keys:
> michael <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> Use free-form input when possible.
> - The Elements of Programming Style (Kernighan & Plaugher)
>
> !DSPAM:50f7b55f133081298090781!

-- 
Hilsen/regards
Michael Rasmussen