On Fri, Apr 05, 2019 at 02:19:25PM +0200, Martin Kletzander wrote:
On Fri, Apr 05, 2019 at 10:33:05AM +0100, Richard W.M. Jones wrote:
>From: Martin Kletzander <mkletzan(a)redhat.com>
>
>Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
Just to mention, this is not complete yet. The disk needs to be opened as
SINGLE_LINK only for the purpose of extents(), but without that flag for
reading. I hope VDDK let's us have two concurrent handles to the same disk with
different open flags. If not, there are other ways, of course.
I think there are a couple of implicit questions here:
(1) Can VDDK (actually, VMware server) handle two connections to the
same disk image, both open for reading and with different flags?
The answer to that is yes. Running these two sets of commands in
parallel works fine for me:
$ LD_LIBRARY_PATH=vddk/vmware-vix-disklib-distrib/lib64 \
./nbdkit vddk file="[datastore1] Fedora 28/Fedora 28.vmdk" \
libdir=vddk/vmware-vix-disklib-distrib \
server=vmware user=root password=- \
thumbprint=xx vm=moref=3 \
-fv -r -p 10809 single-link=true &
$ qemu-img convert nbd:localhost:10809 /var/tmp/out
$ LD_LIBRARY_PATH=vddk/vmware-vix-disklib-distrib/lib64 \
./nbdkit vddk file="[datastore1] Fedora 28/Fedora 28.vmdk" \
libdir=vddk/vmware-vix-disklib-distrib \
server=vmware user=root password=- \
thumbprint=xx vm=moref=3 \
-fv -r -p 10810 &
$ qemu-img convert nbd:localhost:10810 /var/tmp/out2
(2) Can we do this all in one nbdkit process?
Maybe but it's a large architectural for the VDDK plugin from what we
have right now.
We could fork the VDDK plugin or hack things in the current plugin,
but instead is it possible to do this from two nbdkit processes?
ie: We'd have one which does the map and a second which does the read
from the mapped areas?
This pushes the complexity up to qemu-img, but if we think that
qemu-img cannot actually do what we want for other reasons and we're
going to need to write a small "copier" program, then having it open
two NBD connections instead of one isn't a big deal IMO.
nbdkit itself is explicitly designed for this situation however. Soon
virt-v2v could be running half a dozen nbdkit subprocesses for common
conversion scenarios. nbdkit is designed to be used as a captive
subprocess
(
https://github.com/libguestfs/nbdkit/blob/master/docs/nbdkit-captive.pod)
If we do this then the patch as it stands would be fine.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v