search for: disk_sync

This is based on top of: https://github.com/nertpinx/v2v-conversion-host/commit/0bb2efdcacd975a2cae7380080991ac7fc238d2b The first 4 patches are fairly uncontroversial miscellaneous cleanups. Patch 5 is the interesting one. (Note it doesn't quite work yet, so it's for discussion only.) Patch 5 converts the inner loop to use asynchronous libnbd calls. performance improves quite a bit for

...in nbd_handle). The server will answer these in parallel and possibly out of order. This results in somewhat better throughput (for me: 13 minutes down to 5 minutes for an "initial" run). Although unfortunately we are still limited by VDDK's braindead threading model. --- wrapper/disk_sync.py | 55 +++++++++++++++++++++++++++++++------------- 1 file changed, 39 insertions(+), 16 deletions(-) diff --git a/wrapper/disk_sync.py b/wrapper/disk_sync.py index e655ead..e854009 100644 --- a/wrapper/disk_sync.py +++ b/wrapper/disk_sync.py @@ -409,6 +409,26 @@ def get_block_status(nbd_handle,...

...will answer these in parallel and possibly >out of order. > >This results in somewhat better throughput (for me: 13 minutes down to >5 minutes for an "initial" run). Although unfortunately we are still >limited by VDDK's braindead threading model. >--- > wrapper/disk_sync.py | 55 +++++++++++++++++++++++++++++++------------- > 1 file changed, 39 insertions(+), 16 deletions(-) > >diff --git a/wrapper/disk_sync.py b/wrapper/disk_sync.py >index e655ead..e854009 100644 >--- a/wrapper/disk_sync.py >+++ b/wrapper/disk_sync.py >@@ -409,6 +409,26 @@ def...

...possibly > >out of order. > > > >This results in somewhat better throughput (for me: 13 minutes down to > >5 minutes for an "initial" run). Although unfortunately we are still > >limited by VDDK's braindead threading model. > >--- > >wrapper/disk_sync.py | 55 +++++++++++++++++++++++++++++++------------- > >1 file changed, 39 insertions(+), 16 deletions(-) > > > >diff --git a/wrapper/disk_sync.py b/wrapper/disk_sync.py > >index e655ead..e854009 100644 > >--- a/wrapper/disk_sync.py > >+++ b/wrapper/disk_sync.py...

This was the first version with the stable API and all the fixes required to make the Python bindings not crash when used asynchronously. --- wrapper/disk_sync.py | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/wrapper/disk_sync.py b/wrapper/disk_sync.py index e830193..e655ead 100644 --- a/wrapper/disk_sync.py +++ b/wrapper/disk_sync.py @@ -4,6 +4,8 @@ from pyVmomi import vim from pyVim.connect import SmartConnect, Disconnect from pyVim...

Even though this option is not to be used according to the manual, it: a) still might be useful even for machine-readable logs b) should not break the machine-readable output Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- v2v/v2v.ml | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index

...able output > >I'm a bit confused what you're trying to do here. > When working on a conversion where the disk is already copied from the source hypervisor to the destination storage (due to various reasons, e.g. having faster access to one of the storages or being able to use the disk_sync script to prefetch some of the data before the machine gets shut down) I need to utilize virt-v2v for two specific purposes: 1) to create the output metadata and 2) to make the changes in the guest disks (which are already copied) but not for the third thing that virt-v2v does as well, which i...