Add v2v presentation.

diff --git a/2017-v2v-internals/NOTES b/2017-v2v-internals/NOTES
new file mode 100644 (file)
index 0000000..51879fa
--- /dev/null
+++ b/2017-v2v-internals/NOTES
@@ -0,0 +1,225 @@
+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)

diff --git a/2017-v2v-internals/presentation.odp b/2017-v2v-internals/presentation.odp
new file mode 100644 (file)
index 0000000..7484853
Binary files /dev/null and b/2017-v2v-internals/presentation.odp differ