The virt-v2v tests here are not meant to be thorough tests of guest
conversion. There is a test suite used to test conversion which is
kept outside libguestfs because it contains lots of proprietary
unredistributable guests like Windows.
The tests here instead are testing:
- virt-v2v command line arguments
- virt-v2v reads and writes files to the correct places
- valgrind & memory leaks
- any conversion properties that can be tested using just the
phony guests (but we don't go out of our way here)
- that up to date guests don't crash virt-v2v
For example:
$ time ./run ./tests/qemu/qemu-boot -n 100
real 1m19.794s
user 0m10.001s
sys 0m5.928s
will run 100 appliance start/stops, from multiple threads.
Previously it wasn't installed at all. However it makes sense to
install it somewhere so that it can be placed in a package (a
requirement if we're going to create a kickstart). By placing it in
libexecdir it is hopefully clear that it should not be used.
Note on Red Hat distros, libexecdir is usually /usr/libexec. On
Debian it is usually /usr/lib/libguestfs.
It is not possible to have the ISO be built automatically when the
user runs 'make'. The README file describes how you should go about
building the ISO or disk image.
This is a graphical standalone front-end to virt-v2v which can be run
on physical machines (usually linked into a ISO or PXE boot image) to
convert the physical machine to a virtual machine.
There are two observations which make this possible: (1) virt-sparsify
contains at least one C unit, so automake thinks it is compiling a C
program. (2) Automake lets us add a *_LINK rule to override linking.
We list the C sources of virt-sparsify as virt_sparsify_SOURCES, so
automake thinks it is building a C program as normal.
We override virt_sparsify_LINK to make it actually link an OCaml
program.
We add virt_sparsify_DEPENDENCIES listing the OCaml objects so that
they get built before linking.
We need a small linker script (link.sh) which adds some options at the
end of the linker command line which are impossible to add using pure
automake.
Inspired by the same idea in supermin:
https://github.com/libguestfs/supermin/blob/master/src/Makefile.am
Currently the backend settings are treated as a list of strings. You
can set the whole list (clearing any strings there previously), but
you cannot search for an individual string or replace an individual
string.
This adds further APIs allowing you to do that. We treat the backend
settings as a list of environment-like strings (ie. name=value), and
add the following functions:
- set-backend-setting (name, value)
Set name=value. Any previous settings of name are cleared.
- get-backend-setting (name)
Search for name or name=value and return the value.
- clear-backend-setting (name)
Remove any name or name=value settings.
This also adds a regression test.
This is not used by libguestfs right now, but it does allow you to
build a python "distribution" of libguestfs, like this:
make -C python sdist
The distribution tarball will be in python/dist/
You can copy the distribution tarball somewhere, unpack it, and use
regular 'python setup.py' commands such as:
python setup.py build
python setup.py install [--prefix=...]
python setup.py --name
In future we hope to be able to upload the distribution tarball to
PyPi, but licensing issues prevent this at present.
Split virt-builder into build and customize steps, so that we can spin
off a separate tool called 'virt-customize'. This commit does not in
fact create such a tool, but it moves all the common code into a
library, in the customize/ subdirectory of the source.
Although this is mostly refactoring, it does change the order in which
virt-builder command line arguments are processed, so they are now
processed in the order they appear, not the inflexible fixed order
used before.
Since the default PHP test runner ignores a good number of environment
variables to potentially tampering the test suite execution, create a
custom php-for-tests.sh script which does nothing more than sourcing the
custom environment that our run-php-tests.sh outputs and running the
actual "php" executable (the one found by configure).
This fixes the loading of the guestfs_php.so module in the test suite,
as the libguestfs.so.0 library can be found by that module.
Introduce and use simple .conf files to configure the sources of indexes
for virt-builder. The location of these files is in XDG_CONFIG_DIRS /
XDG_CONFIG_HOME, so it can be easily overridden.
There are three .conf(.in) files shipped with this commit:
- "test-index.conf.in" (in "test-config"), which points to the
"test-index" index (used in tests only); the tests are adapted to
point to the hierarchy containing this .conf
- "libguestfs.conf.in" (in "test-website"), which points to the local
"index.asc" (i.e. the offline copy of the libguestfs.org index);
run(.in) will point to the hierarchy providing this .conf
- "libguestfs.conf.in" (directly among the other sources), which points
to the online "index.asc" and it is installed in sysconfdir, along
with the key of this repository
The tests are adapted, other than to the different way to pick sources,
to the different output of --list, as "test-index" is not signed.
virt-builder and virt-sysprep may make use of
Common_utils.string_random8 (which uses Random.int) for constructing
temporary paths; not initialising the random generator means that every
invocation will reuse the same name used previously (!).
Thus just call Random.self_init, just like virt-sparsify already does.
Expand the test-virt-sysprep-script.sh test to ensure that virt-sysprep
is not affected again by this issue.
All it did was checking for a libvirt version, which is what
libvirt-is-version now does; hence remove the C part, and use guestfish,
ignoring the launch failure (as the C test did).
This tests that libvirt domain XML (ie. guestfish -d option) is parsed
correctly and results in the correct qemu command line when using the
direct backend.
This is a good end-to-end test of various layers.
Review every test(!) to ensure that it:
- Doesn't use a generic name (eg. "test1.img", "test.out") for any
temporary file it needs.
- Does instead use a unique name or a temporary name (eg. a name like
"name-of-the-test.img", or a scratch disk).
- Does not use 'rm -f' to clean up its temporary files (so we can
detect errors if the wrong temporary file is created or removed).
This allows tests to be run in parallel, so they don't stomp on each
other's temporary files.
