[Libguestfs] virt-v2v slow when running inside the VM

Richard W.M. Jones rjones at redhat.com
Wed Apr 10 17:30:21 UTC 2019


On Wed, Apr 10, 2019 at 10:15:43AM -0700, Sureshkumar Kaliannan wrote:
> thanks Richard,
> 
> The experiment was indeed done with nested VM enabled. I am not sure about
> the internals, but i thought once overlay is setup the 2 main processes are
> sshd and qemu-img convert (reading data from sshd and doing the conversion)

Yes this should be true.  I wouldn't expect copying to be slower.

So initial guess probably wrong.  I wonder if there are some extra
steps such as a slow software bridge or openvswitch on the host?

> I don't see any of the qemu process running.

As per http://libguestfs.org/virt-p2v.1.html#how-virt-p2v-works you
should see qemu-nbd running on the physical server, and qemu-img
running on the conversion server during the copying phase.

> Initial overlay setup was pretty quick and rest of the time was spent in
> qemu-img convert operation

Indeed qemu should exit before copying starts.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/




More information about the Libguestfs mailing list