From: Richard W.M. Jones Date: Thu, 2 Nov 2017 22:51:41 +0000 (+0000) Subject: Add v2v presentation. X-Git-Url: http://git.annexia.org/?a=commitdiff_plain;h=19f36cd7f397731c1bacaf49a8b029f1a77a3c9e;p=libguestfs-talks.git Add v2v presentation. --- diff --git a/2017-v2v-internals/NOTES b/2017-v2v-internals/NOTES new file mode 100644 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 index 0000000..7484853 Binary files /dev/null and b/2017-v2v-internals/presentation.odp differ