Proxmox/pve-manager
5
0
Fork 0
Code Pull Requests Releases Activity
pve-manager/test/replication_test5.log

61 lines
4.7 KiB
Plaintext
Raw Permalink Normal View History

PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
1000 job_900_to_node2: new job next_sync => 900
1000 job_900_to_node2: start replication job
replication: fix regression tests
2017-06-29 07:46:56 +02:00
1000 job_900_to_node2: guest => VM 900, running => 0
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
1000 job_900_to_node2: volumes => local-zfs:vm-900-disk-1
use new PVE::ReplicationState::replication_snapshot_name()
2017-06-06 12:02:53 +02:00
1000 job_900_to_node2: create snapshot '__replicate_job_900_to_node2_1000__' on local-zfs:vm-900-disk-1
1000 job_900_to_node2: full sync 'local-zfs:vm-900-disk-1' (__replicate_job_900_to_node2_1000__)
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
1000 job_900_to_node2: end replication job
1000 job_900_to_node2: changed config next_sync => 1800
replication: add last_node to replication state So that we know which node produced the state. This is not always the local node, because we copy the state on migrate.
2017-06-06 06:49:05 +02:00
1000 job_900_to_node2: changed state last_node => node1, last_try => 1000, last_sync => 1000
replication: save list of used storage IDs
2017-06-06 09:54:53 +02:00
1000 job_900_to_node2: changed storeid list local-zfs
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
1840 job_900_to_node2: start replication job
replication: fix regression tests
2017-06-29 07:46:56 +02:00
1840 job_900_to_node2: guest => VM 900, running => 0
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
1840 job_900_to_node2: volumes => local-zfs:vm-900-disk-1
use new PVE::ReplicationState::replication_snapshot_name()
2017-06-06 12:02:53 +02:00
1840 job_900_to_node2: create snapshot '__replicate_job_900_to_node2_1840__' on local-zfs:vm-900-disk-1
1840 job_900_to_node2: incremental sync 'local-zfs:vm-900-disk-1' (__replicate_job_900_to_node2_1000__ => __replicate_job_900_to_node2_1840__)
replication: improve stale volume detection, allow sync from parent snapshot We pass a list of storage to scan for stale volumes to prepare_local_job(). So we make sure that we only activate/scan related storages. Snapshot rollback may remove local replication shapshots. In that case we still have the $conf->{parent} snapshot on both sides, so we can use that as base snapshot.
2017-06-07 09:30:52 +02:00
1840 job_900_to_node2: delete previous replication snapshot '__replicate_job_900_to_node2_1000__' on local-zfs:vm-900-disk-1
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
1840 job_900_to_node2: end replication job
1840 job_900_to_node2: changed config next_sync => 2700
1840 job_900_to_node2: changed state last_try => 1840, last_sync => 1840
2740 job_900_to_node2: start replication job
replication: fix regression tests
2017-06-29 07:46:56 +02:00
2740 job_900_to_node2: guest => VM 900, running => 0
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
2740 job_900_to_node2: volumes => local-zfs:vm-900-disk-1,local-zfs:vm-900-disk-2
use new PVE::ReplicationState::replication_snapshot_name()
2017-06-06 12:02:53 +02:00
2740 job_900_to_node2: create snapshot '__replicate_job_900_to_node2_2740__' on local-zfs:vm-900-disk-1
2740 job_900_to_node2: create snapshot '__replicate_job_900_to_node2_2740__' on local-zfs:vm-900-disk-2
replication: improve stale volume detection, allow sync from parent snapshot We pass a list of storage to scan for stale volumes to prepare_local_job(). So we make sure that we only activate/scan related storages. Snapshot rollback may remove local replication shapshots. In that case we still have the $conf->{parent} snapshot on both sides, so we can use that as base snapshot.
2017-06-07 09:30:52 +02:00
2740 job_900_to_node2: delete previous replication snapshot '__replicate_job_900_to_node2_2740__' on local-zfs:vm-900-disk-1
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
2740 job_900_to_node2: end replication job with error: no such volid 'local-zfs:vm-900-disk-2'
2740 job_900_to_node2: changed config next_sync => 3040
2740 job_900_to_node2: changed state last_try => 2740, fail_count => 1, error => no such volid 'local-zfs:vm-900-disk-2'
3040 job_900_to_node2: start replication job
replication: fix regression tests
2017-06-29 07:46:56 +02:00
3040 job_900_to_node2: guest => VM 900, running => 0
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
3040 job_900_to_node2: volumes => local-zfs:vm-900-disk-1,local-zfs:vm-900-disk-2
use new PVE::ReplicationState::replication_snapshot_name()
2017-06-06 12:02:53 +02:00
3040 job_900_to_node2: create snapshot '__replicate_job_900_to_node2_3040__' on local-zfs:vm-900-disk-1
3040 job_900_to_node2: create snapshot '__replicate_job_900_to_node2_3040__' on local-zfs:vm-900-disk-2
3040 job_900_to_node2: incremental sync 'local-zfs:vm-900-disk-1' (__replicate_job_900_to_node2_1840__ => __replicate_job_900_to_node2_3040__)
3040 job_900_to_node2: full sync 'local-zfs:vm-900-disk-2' (__replicate_job_900_to_node2_3040__)
replication: improve stale volume detection, allow sync from parent snapshot We pass a list of storage to scan for stale volumes to prepare_local_job(). So we make sure that we only activate/scan related storages. Snapshot rollback may remove local replication shapshots. In that case we still have the $conf->{parent} snapshot on both sides, so we can use that as base snapshot.
2017-06-07 09:30:52 +02:00
3040 job_900_to_node2: delete previous replication snapshot '__replicate_job_900_to_node2_1840__' on local-zfs:vm-900-disk-1
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
3040 job_900_to_node2: end replication job
3040 job_900_to_node2: changed config next_sync => 3600
3040 job_900_to_node2: changed state last_try => 3040, last_sync => 3040, fail_count => 0, error =>
3640 job_900_to_node2: start replication job
replication: fix regression tests
2017-06-29 07:46:56 +02:00
3640 job_900_to_node2: guest => VM 900, running => 0
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
3640 job_900_to_node2: volumes => local-zfs:vm-900-disk-1,local-zfs:vm-900-disk-2
use new PVE::ReplicationState::replication_snapshot_name()
2017-06-06 12:02:53 +02:00
3640 job_900_to_node2: create snapshot '__replicate_job_900_to_node2_3640__' on local-zfs:vm-900-disk-1
3640 job_900_to_node2: create snapshot '__replicate_job_900_to_node2_3640__' on local-zfs:vm-900-disk-2
3640 job_900_to_node2: incremental sync 'local-zfs:vm-900-disk-1' (__replicate_job_900_to_node2_3040__ => __replicate_job_900_to_node2_3640__)
3640 job_900_to_node2: incremental sync 'local-zfs:vm-900-disk-2' (__replicate_job_900_to_node2_3040__ => __replicate_job_900_to_node2_3640__)
replication: improve stale volume detection, allow sync from parent snapshot We pass a list of storage to scan for stale volumes to prepare_local_job(). So we make sure that we only activate/scan related storages. Snapshot rollback may remove local replication shapshots. In that case we still have the $conf->{parent} snapshot on both sides, so we can use that as base snapshot.
2017-06-07 09:30:52 +02:00
3640 job_900_to_node2: delete previous replication snapshot '__replicate_job_900_to_node2_3040__' on local-zfs:vm-900-disk-1
3640 job_900_to_node2: delete previous replication snapshot '__replicate_job_900_to_node2_3040__' on local-zfs:vm-900-disk-2
PVE::Replication::replicate - implement replicate The actual volume replication is done in replicate_volume(), which is just a stub for now. I also added a regression test replication_test5.pl to verify basic functions.
2017-05-23 07:40:30 +02:00
3640 job_900_to_node2: end replication job
3640 job_900_to_node2: changed config next_sync => 4500
3640 job_900_to_node2: changed state last_try => 3640, last_sync => 3640
replication_test5.pl: add test for job removal
2017-05-30 14:40:08 +02:00
3700 job_900_to_node2: start replication job
replication: fix regression tests
2017-06-29 07:46:56 +02:00
3700 job_900_to_node2: guest => VM 900, running => 0
replication_test5.pl: add test for job removal
2017-05-30 14:40:08 +02:00
3700 job_900_to_node2: volumes => local-zfs:vm-900-disk-1,local-zfs:vm-900-disk-2
3700 job_900_to_node2: start job removal - mode 'full'
replication: improve stale volume detection, allow sync from parent snapshot We pass a list of storage to scan for stale volumes to prepare_local_job(). So we make sure that we only activate/scan related storages. Snapshot rollback may remove local replication shapshots. In that case we still have the $conf->{parent} snapshot on both sides, so we can use that as base snapshot.
2017-06-07 09:30:52 +02:00
3700 job_900_to_node2: delete stale replication snapshot '__replicate_job_900_to_node2_3640__' on local-zfs:vm-900-disk-1
3700 job_900_to_node2: delete stale replication snapshot '__replicate_job_900_to_node2_3640__' on local-zfs:vm-900-disk-2
replication_test5.pl: add test for job removal
2017-05-30 14:40:08 +02:00
3700 job_900_to_node2: job removed
3700 job_900_to_node2: end replication job
3700 job_900_to_node2: vanished job
Copy Permalink