If ntfs-3g is not installed, then tests/guests creates a 'windows.img'
file which is zero-sized.
This is problematical because other tests which use this image will
fail at best, or hit RHBZ#847549 (qemu/virtio-scsi bug) at worst.
Change the tests which use windows.img so they skip if 'windows.img'
has zero size.
When executing a command, we temporarily chroot, fork and exec the
command, then chroot back. We intentionally don't chdir in the parent
process so that we can 'jailbreak' the chroot later. However, this has
the effect that commands are executed with a current working directory
which is outside the current root. This unusual state can cause
errors in executed commands which don't anticipate it.
This change does a chdir("/") before executing and command. This
happens inside the fork, so the jailbreak isn't affected in the
parent.
These configure flags enable code profiling (with gprof) and code
coverage (with gcov) respectively.
Although this is a nice idea, it's not currently very useful.
Libtool mangles filenames in such a way that gcov cannot locate its
datafiles.
Profiling is of dubious utility with libguestfs which is not CPU-bound
and relies extensively on running external programs (oprofile-like
system profiling that took into account libguestfs + qemu or
libguestfs + qemu + the appliance + filesystem tools *would* be
useful).
Also neither flag will help in capturing data from the appliance.
This file was present in git, but missing from the tarball.
Don't actually run the test: it depends on details of how the
appliance is constructed which would fail for old-style appliances.
'make extra-tests' was a monolithic set of tests that did all sorts of
things: valgrind, tests over local guests, tests with upstream qemu,
tests with upstream libvirt, tests with the appliance attach method.
This made it hard to perform individual tests, eg. just valgrind
testing. It was also hard to maintain because the tests were not
located in the same directories as the programs and sometimes
duplicated tests that were run elsewhere.
This commit splits up 'make extra-tests' into 5 separate targets:
make check-valgrind # run a subset of tests under valgrind
make check-valgrind-local-guests # test under valgrind with local guests
make check-with-appliance # test with attach-method == appliance
make check-with-upstream-qemu # test with an alternate/upstream qemu
make check-with-upstream-libvirt # test with an alternate/upstream libvirt
(You can also still run 'make extra-tests' which is now simply
a rule that runs the above 5 targets in order).
This replaces everything that was in the tests/extra directory,
so that has now gone.
This is mostly just code motion, but it also changes the default
location where valgrind.log is written to be the top build directory
(instead of tests/extra/valgrind.log).
New APIs: set-tmpdir, get-tmpdir, set-cachedir, get-cachedir.
The current code has evolved over time and has a number of problems:
(a) A single environment variable ($TMPDIR) controls the
location of several directories.
(b) It's hard for the library user to predict which directory
libguestfs will use, unless the user simulates the same internal steps
that libguestfs performs.
This commit fixes these issues.
(a) Now three environment variables control the location of all small
temporary files, and the appliance cache:
For temporary files: $LIBGUESTFS_TMPDIR or $TMPDIR or /tmp.
For the appliance cache: $LIBGUESTFS_CACHEDIR or $TMPDIR or /var/tmp.
The user can also set these directories explicitly through API calls
(guestfs_set_tmpdir and guestfs_set_cachedir).
(b) The user can also retrieve the actual directories that libguestfs
will use, by calling guestfs_get_tmpdir and guestfs_get_cachedir.
These functions are also used internally.
This commit also:
- reworks the internal tmpdir code
- removes the internal (undocumented) guestfs_tmpdir call (replacing
it with calls to the documented guestfs_get_tmpdir API instead)
- changes the ./run script to set LIBGUESTFS_TMPDIR and
LIBGUESTFS_CACHEDIR
- adds a test
- fixes a few places like libguestfs-make-fixed-appliance which
depended on $TMPDIR
Commit ed7fda161e changed the
way that the drives are handled across appliance shutdowns.
Previously during the following sequence of calls:
create the handle
add drive(s)
launch
kill subprocess
launch
the added drives are still in the handle at the second launch.
After the above commit, the added drives are removed from the handle,
which means the second launch happens with no drives (which could be
an error).
This was never actually defined either way, so in this case fix the
test to re-add the drive before the second launch.
Since hotplugging was added, it isn't really feasible to return to the
original semantics, since users might remove drives, in which case we
have lost information about those drives so we cannot restore them on
the second launch.
NOTE: PLEASE CALLERS DON'T DO THIS! Always use a new handle for each
launch of the appliance.
When libvirt is used, we can allow disks to be hotplugged.
guestfs_add_drive can be called after launch to hot-add a disk.
When a disk is hot-added, we first ask libvirt to add the disk to the
appliance, then we make an internal call into the appliance to get it
to wait for the disk to appear (ie. udev_settle ()).
Hot-added disks are tracked in the g->drives array.
This also adds a test.
New API: list-disk-labels
Allow the user to pass an optional disk label when adding a drive.
This is passed through to qemu / libvirt using the disk serial field,
and from there to the appliance which exposes it through udev,
creating a special alias of the device /dev/disk/guestfs/<label>.
Partitions are named /dev/disk/guestfs/<label><partnum>.
virtio-blk and virtio-scsi limit the serial field to 20 bytes. We
further limit the name to maximum 20 ASCII characters in [a-zA-Z].
list-devices and list-partitions are not changed: these calls still
return raw block device names. However a new call, list-disk-labels,
returns a hash table allowing callers to map between disk labels, and
block device and partition names.
This commit also includes a test.
Let tests/bigdirs/test-big-dirs.pl uses mke2fs to create small
inode ratio files.
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
RWMJ:
- Fix invocation of mke2fs with optional arguments.
- Run the test to check it works.
Without this empty rule, automake doesn't generate the rest of the
testing infrastructure, so you can't enable the test yourself by doing
'make check TESTS=test-big-dirs.pl'.
Passing the $upstream_qemu environment variable is not reliable when
libvirt is involved: Environment variables are passed to the first
instance of the session libvirtd, but because libvirt reuses the
session libvirtd, subsequent environment variable settings are lost
(this is filed as RHBZ#856619).
Bypass all of this by writing a custom qemu-wrapper.sh which contains
the hard-coded values we want.
Since 'QEMU' is set (overwritten) by the autoconf-generated Makefile,
this test would always test installed qemu, not upstream qemu,
making it pretty useless. Use another name for this variable.
libguestfs fails to build with --enable-fuse on openSuSE 11.4 and
earlier because the included fuse version does not include
libulockmgr.so. configure already used pkgconfig to retrieve the correct
CFLAGS, so there is no need to hardcode -lulockmgr.
With this change the build succeeds again.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
