Quick demo:

  $ virt-v2v -i ova RHEL.ova -o local -os /var/tmp

OVA was exported from VMware.  Convenient to use OVAs for the demo
because it doesn't require a running VMware server.

Output is stored locally, but in a more realistic scenario you would
point virt-v2v directly at RHV, Glance or other targets.

No need to run it as root unless it needs to be run as root to
access something.

Input mode and an output mode
-----------------------------

There's an input mode, an output mode, and a conversion step between
them.

    virt-v2v -i ova RHEL.ova
             -i vmx guest.vmx
             -i libvirt -ic vpx://vcenter.example.com/Datacenter/esxi guest
             -i disk disk.img

             -o local -os /var/tmp
             -o libvirt
             -o rhv -os esd:/mnt
             -o glance
             -o qemu   \__ for testing
             -o null   /


Overlay on top of input, conversion, then qemu-img convert
----------------------------------------------------------

Conversion is actually done first, but the "delta" is stored in an
overlay, which is a local qcow2 file in /var/tmp.  The source is never
touched.

The second step is a copy made to the target using ‘qemu-img convert’.

The copy is the long step, and we want to do the conversion first
because conversion is the most likely part to fail.

‘fstrim’ is used to reduce the amount of data copied.  Blank areas and
deleted files are almost never copied.


Source
------

Virt-v2v has an internal structure that reflects the command line.

https://github.com/libguestfs/libguestfs
  - v2v subdirectory is the source of virt-v2v
  - p2v subdirectory is the source of virt-p2v
  - About 33 K LoC in virt-v2v & virt-p2v
  - About 860 K LoC if you include all parts of the libguestfs ecosystem
    (tools, utilities, libraries, hivex, supermin, nbdkit)

Before compiling, read: http://libguestfs.org/guestfs-building.1.html
Very important indeed and it will save you a lot of time and hassle.

It's written in OCaml and C.  OCaml is a very fast, natively compiled,
actively developed ML derivative.

When reading OCaml code, always start with the .mli file -- the
interface.  Then read the .ml file -- the implementation -- if you
need it.


Input modules
-------------

Input_ova
(-i ova)

Input_vmx
(-i vmx)
                             source structure
Input_libvirt*               + inspection data
(VMware, Xen, ...)

Input_disk
(-i disk)


Source + inspection
-------------------

This is very abbreviated.  In the real structure there are dozens
of fields and sub-structures.

It's like libvirt XML, but more limited.

Inspection data is collected from the source automatically and it
contains a very large amount of detail about the guest, including type
(Linux, Windows), architecture, applications installed and so on.


Conversion modules
------------------

source + inspection        Convert_linux

                           Convert_windows

Remember that the conversion step is done up-front.  The inspection
data tells us whether we need to use the Linux or Windows module.
Only a limited set of Linux distros are supported, but almost any
Windows version is supported.


Conversion of Linux
-------------------

* Removes guest additions.

* Picks a kernel with virtio support and adjusts the bootloader to use it.
  It can also handle guests with no virtio support and Do The Right Thing.

* Changes devices names in configuration files (eg. /dev/vdaX).

* Rebuilds the initramfs.


Conversion of Windows
---------------------

Much more complex than Linux conversion.  Unlike Linux conversions,
we will actually install virtio-win drivers.

* Removes some guest additions and Xen drivers.

* Dozens of changes to the Windows Registry.

* Changes to the BCD.

* The installations and changes are continued in a "firstboot" script
  which runs on first boot of the guest in the new environment.

Auxiliary programs: pnp_wait.exe, rhsrvany.exe, rhev-apt.exe, vmdp.exe [SUSE].


Output module
-------------

Output_glance
(-o glance)

Output_rhv / Output_vdsm
(for RHV)

Output_libvirt
(-o libvirt)

Output_local, Output_null, Output_qemu
(-o local, -o null, -o qemu)


Unlike input modules which collect data and create the "source"
struct, the purpose of output modules is more to manage the final
copy/qemu-img convert step.

Output modules also create the final metadata.  The metadata is
influenced by the conversion step: for example if virtio drivers could
not be installed then the metadata will specify emulated (eg. IDE)
devices.


Managing the process
--------------------

V2v module manages the whole process end to end.  It's the "main
program" of virt-v2v.


Libraries and utilities
-----------------------





Tests
-----

virt-v2v has (at least?) 3 test suites:

* An internal test suite run by doing ‘make check’

* An external test suite of proprietary images

* AvocadoVT tests maintained by QE

We'll probably move (2) into (3) at some point.



Other topics
------------

Don't want to talk about these, but don't want to forget about them
either, since they are complex and important topics on their own.

* virt-p2v

* --in-place conversions


Final notes
-----------

http://libguestfs.org

https://github.com/libguestfs/libguestfs

http://libguestfs.org/guestfs-building.1.html

IRC: #libguestfs on Freenode (public)

IRC: #v2v (internal)

Mail: libguestfs@redhat.com (public)
      v2v-devel (internal)