mirror of
https://github.com/libguestfs/libguestfs.git
synced 2026-03-21 22:53:37 +00:00
p2v, v2v: Move HACKING documentation to guestfs-hacking(1) manual page.
This commit is contained in:
Richard W.M. Jones
@@ -676,6 +676,86 @@ Language bindings.
|
||||
|
||||
=back
|
||||
|
||||
=head2 VIRT-V2V
|
||||
|
||||
First a little history. Virt-v2v has been through at least two
|
||||
complete rewrites, so this is probably about the third version (but we
|
||||
don't intend to rewrite it again). The previous version was written
|
||||
in Perl and can be found here:
|
||||
L<https://git.fedorahosted.org/git/virt-v2v.git>
|
||||
|
||||
The current version started out as almost a line-for-line rewrite of
|
||||
the Perl code in OCaml + C, and it still has a fairly similar
|
||||
structure. Therefore if there are details of this code that you don't
|
||||
understand (especially in the details of guest conversion), checking
|
||||
the Perl code may help.
|
||||
|
||||
The files to start with when reading this code are:
|
||||
|
||||
=over 4
|
||||
|
||||
=item *
|
||||
|
||||
F<types.mli>
|
||||
|
||||
=item *
|
||||
|
||||
F<v2v.ml>
|
||||
|
||||
=back
|
||||
|
||||
F<types.mli> defines all the structures used and passed around when
|
||||
communicating between different bits of the program. F<v2v.ml>
|
||||
controls how the program runs in stages.
|
||||
|
||||
After studying those files, you may want to branch out into the input
|
||||
modules (F<input_*>), the output modules (F<output_*>) or the
|
||||
conversion modules (F<convert_*>). The input and output modules
|
||||
define I<-i> and I<-o> options (see the manual). The conversion
|
||||
modules define what guest types we can handle and the detailed steps
|
||||
involved in converting them.
|
||||
|
||||
Every other file in this directory is a support module / library of
|
||||
some sort. Some code is written in C, especially where we want to use
|
||||
an external C library such as libxml2.
|
||||
|
||||
=head2 VIRT-P2V
|
||||
|
||||
Virt-p2v is a front end on virt-v2v. ie. All it does is act as a GUI
|
||||
front end, and it calls out to virt-v2v to perform the actual
|
||||
conversion. Therefore most of the C code in the F<p2v/> subdirectory
|
||||
is Gtk (GUI) code, or supporting code for talking to the remote
|
||||
conversion server. There is no special support for physical machines
|
||||
in virt-v2v. They are converted in the same way as foreign VMs.
|
||||
|
||||
There are two paths through the code, GUI or non-GUI (parsing the
|
||||
kernel command line):
|
||||
|
||||
main.c --+----> gui.c -----+----> conversion.c
|
||||
| |
|
||||
| |
|
||||
`----> kernel.c -----'
|
||||
|
||||
but both paths call back to the F<conversion.c> function
|
||||
C<start_conversion> to run the remote virt-v2v.
|
||||
|
||||
The main task of F<gui.c>/F<kernel.c> is to populate the virt-v2v
|
||||
configuration (F<config.c>).
|
||||
|
||||
During conversion, we need to establish ssh connections, and that is
|
||||
done using two libraries:
|
||||
|
||||
conversion.c ------> ssh.c ------> miniexpect.c
|
||||
|
||||
where F<ssh.c> is responsible for managing ssh connections overall,
|
||||
and F<miniexpect.c> implements "expect-like" functionality for talking
|
||||
interactively to the remote virt-v2v conversion server.
|
||||
|
||||
(Note that miniexpect is a separate library with its own upstream, so
|
||||
if you patch miniexpect.c, then please make sure the changes get
|
||||
reflected in miniexpect's upstream too:
|
||||
F<http://git.annexia.org/?p=miniexpect.git;a=summary>)
|
||||
|
||||
=head2 MAKING A STABLE RELEASE
|
||||
|
||||
When we make a stable release, there are several steps documented
|
||||
|
||||
36
p2v/HACKING
36
p2v/HACKING
@@ -1,36 +0,0 @@
|
||||
To see about hacking on virt-v2v, see v2v/HACKING.
|
||||
|
||||
Virt-p2v is a front end on virt-v2v. ie. All it does is act as a GUI
|
||||
front end, and it calls out to virt-v2v to perform the actual
|
||||
conversion. Therefore most of the C code in the p2v/ subdirectory is
|
||||
Gtk (GUI) code, or supporting code for talking to the remote
|
||||
conversion server. There is no special support for physical machines
|
||||
in virt-v2v. They are converted in the same way as foreign VMs.
|
||||
|
||||
There are two paths through the code, GUI or non-GUI (parsing the
|
||||
kernel command line):
|
||||
|
||||
main.c --+----> gui.c -----+----> conversion.c
|
||||
| |
|
||||
| |
|
||||
`----> kernel.c -----'
|
||||
|
||||
but both paths call back to the conversion.c function
|
||||
'start_conversion' to run the remote virt-v2v.
|
||||
|
||||
The main task of gui.c/kernel.c is to populate the virt-v2v
|
||||
configuration (config.c).
|
||||
|
||||
During conversion, we need to establish ssh connections, and that is
|
||||
done using two libraries:
|
||||
|
||||
conversion.c ------> ssh.c ------> miniexpect.c
|
||||
|
||||
where 'ssh.c' is responsible for managing ssh connections overall, and
|
||||
'miniexpect.c' implements "expect-like" functionality for talking
|
||||
interactively to the remote virt-v2v conversion server.
|
||||
|
||||
(Note that miniexpect is a separate library with its own upstream, so
|
||||
if you patch miniexpect.c, then please make sure the changes get
|
||||
reflected in miniexpect's upstream too:
|
||||
http://git.annexia.org/?p=miniexpect.git;a=summary )
|
||||
@@ -18,7 +18,6 @@
|
||||
include $(top_srcdir)/subdir-rules.mk
|
||||
|
||||
EXTRA_DIST = \
|
||||
HACKING \
|
||||
dependencies.m4 \
|
||||
issue \
|
||||
launch-virt-p2v.in \
|
||||
|
||||
34
v2v/HACKING
34
v2v/HACKING
@@ -1,34 +0,0 @@
|
||||
If you want to hack on virt-v2v, you've come to the right place ...
|
||||
For virt-p2v, read this file, but also p2v/HACKING.
|
||||
|
||||
First a little history. Virt-v2v has been through at least two
|
||||
complete rewrites, so this is probably about the third version (but we
|
||||
don't intend to rewrite it again). The previous version was written
|
||||
in Perl and can be found here:
|
||||
https://git.fedorahosted.org/git/virt-v2v.git
|
||||
|
||||
The current version started out as almost a line-for-line rewrite of
|
||||
the Perl code in OCaml + C, and it still has a fairly similar
|
||||
structure. Therefore if there are details of this code that you don't
|
||||
understand (especially in the details of guest conversion), checking
|
||||
the Perl code may help.
|
||||
|
||||
The files to start with when reading this code are:
|
||||
|
||||
- types.mli
|
||||
- v2v.ml
|
||||
|
||||
'types.mli' defines all the structures used and passed around when
|
||||
communicating between different bits of the program. 'v2v.ml'
|
||||
controls how the program runs in stages.
|
||||
|
||||
After studying those files, you may want to branch out into the input
|
||||
modules ('input_*'), the output modules ('output_*') or the conversion
|
||||
modules ('convert_*'). The input and output modules define -i and -o
|
||||
options (see the manual). The conversion modules define what guest
|
||||
types we can handle and the detailed steps involved in converting
|
||||
them.
|
||||
|
||||
Every other file in this directory is a support module / library of
|
||||
some sort. Some code is written in C, especially where we want to use
|
||||
an external C library such as libxml2.
|
||||
@@ -22,7 +22,6 @@ EXTRA_DIST = \
|
||||
copy_to_local.ml \
|
||||
v2v_unit_tests.ml \
|
||||
$(TESTS) $(SLOW_TESTS) \
|
||||
HACKING \
|
||||
test-v2v-cdrom.expected \
|
||||
test-v2v-cdrom.xml \
|
||||
test-v2v-i-ova.ovf \
|
||||
|
||||
Reference in New Issue
Block a user