3 $ virt-v2v -i ova RHEL.ova -o local -os /var/tmp
5 OVA was exported from VMware. Convenient to use OVAs for the demo
6 because it doesn't require a running VMware server.
8 Output is stored locally, but in a more realistic scenario you would
9 point virt-v2v directly at RHV, Glance or other targets.
11 No need to run it as root unless it needs to be run as root to
14 Input mode and an output mode
15 -----------------------------
17 There's an input mode, an output mode, and a conversion step between
20 virt-v2v -i ova RHEL.ova
22 -i libvirt -ic vpx://vcenter.example.com/Datacenter/esxi guest
29 -o qemu \__ for testing
33 Overlay on top of input, conversion, then qemu-img convert
34 ----------------------------------------------------------
36 Conversion is actually done first, but the "delta" is stored in an
37 overlay, which is a local qcow2 file in /var/tmp. The source is never
40 The second step is a copy made to the target using ‘qemu-img convert’.
42 The copy is the long step, and we want to do the conversion first
43 because conversion is the most likely part to fail.
45 ‘fstrim’ is used to reduce the amount of data copied. Blank areas and
46 deleted files are almost never copied.
52 Virt-v2v has an internal structure that reflects the command line.
54 https://github.com/libguestfs/libguestfs
55 - v2v subdirectory is the source of virt-v2v
56 - p2v subdirectory is the source of virt-p2v
57 - About 33 K LoC in virt-v2v & virt-p2v
58 - About 860 K LoC if you include all parts of the libguestfs ecosystem
59 (tools, utilities, libraries, hivex, supermin, nbdkit)
61 Before compiling, read: http://libguestfs.org/guestfs-building.1.html
62 Very important indeed and it will save you a lot of time and hassle.
64 It's written in OCaml and C. OCaml is a very fast, natively compiled,
65 actively developed ML derivative.
67 When reading OCaml code, always start with the .mli file -- the
68 interface. Then read the .ml file -- the implementation -- if you
81 Input_libvirt* + inspection data
91 This is very abbreviated. In the real structure there are dozens
92 of fields and sub-structures.
94 It's like libvirt XML, but more limited.
96 Inspection data is collected from the source automatically and it
97 contains a very large amount of detail about the guest, including type
98 (Linux, Windows), architecture, applications installed and so on.
104 source + inspection Convert_linux
108 Remember that the conversion step is done up-front. The inspection
109 data tells us whether we need to use the Linux or Windows module.
110 Only a limited set of Linux distros are supported, but almost any
111 Windows version is supported.
117 * Removes guest additions.
119 * Picks a kernel with virtio support and adjusts the bootloader to use it.
120 It can also handle guests with no virtio support and Do The Right Thing.
122 * Changes devices names in configuration files (eg. /dev/vdaX).
124 * Rebuilds the initramfs.
127 Conversion of Windows
128 ---------------------
130 Much more complex than Linux conversion. Unlike Linux conversions,
131 we will actually install virtio-win drivers.
133 * Removes some guest additions and Xen drivers.
135 * Dozens of changes to the Windows Registry.
137 * Changes to the BCD.
139 * The installations and changes are continued in a "firstboot" script
140 which runs on first boot of the guest in the new environment.
142 Auxiliary programs: pnp_wait.exe, rhsrvany.exe, rhev-apt.exe, vmdp.exe [SUSE].
151 Output_rhv / Output_vdsm
157 Output_local, Output_null, Output_qemu
158 (-o local, -o null, -o qemu)
161 Unlike input modules which collect data and create the "source"
162 struct, the purpose of output modules is more to manage the final
163 copy/qemu-img convert step.
165 Output modules also create the final metadata. The metadata is
166 influenced by the conversion step: for example if virtio drivers could
167 not be installed then the metadata will specify emulated (eg. IDE)
174 V2v module manages the whole process end to end. It's the "main
175 program" of virt-v2v.
178 Libraries and utilities
179 -----------------------
188 virt-v2v has (at least?) 3 test suites:
190 * An internal test suite run by doing ‘make check’
192 * An external test suite of proprietary images
194 * AvocadoVT tests maintained by QE
196 We'll probably move (2) into (3) at some point.
203 Don't want to talk about these, but don't want to forget about them
204 either, since they are complex and important topics on their own.
208 * --in-place conversions
214 http://libguestfs.org
216 https://github.com/libguestfs/libguestfs
218 http://libguestfs.org/guestfs-building.1.html
220 IRC: #libguestfs on Freenode (public)
224 Mail: libguestfs@redhat.com (public)