Allow settings (an arbitrary list of strings) to be passed to the
current backend. This will allow us to tweak how the backend works,
eg. by forcing TCG.
The current add_cdrom way basically appends a new raw "-cdrom /path"
parameter to the qemu invocation (even when using libvirt as backend),
hence such images are seen as "CD-ROM drives" inside the appliance.
However, there is no need for such particular behaviour, as they need to
be handled as normal (read-only) drives.
Adding CD-ROM disk images as drives also changes the device names used
for them inside the appliance from /dev/srN to the usual e.g. /dev/sdX.
These changes fix different issues:
- it is possible to start guestfish without adding disks with -a, then
just add-cdrom and run
- list-devices does not cause guestfsd to crash when sorting the list
of devices (exposed by the test case in RHBZ#563450)
- the result of list-devices now reflects the order images were added
(RHBZ#563450)
add_cdrom is still deprecated, but now in favour of add_drive_ro
(instead of add_drive), with its documentation reflecting that.
Add two small regression tests for the fixes described above.
This adds a new internal API: internal_exit
Only when valgrinding the daemon, have the library call internal_exit
along the close path, and close the sockets first. This ensures we
will see normal valgrind messages (we were only seeing valgrind aborts
before).
Note this is not used in production builds.
When the user has enabled the network (not the default) we upload
/etc/resolv.conf from the host to the appliance /etc/resolv.conf
so that programs in the appliance can contact nameservers.
Commit 9521422ce6 previously changed the
behaviour to copy /etc/resolv.conf into the sysroot when running
commands.
This call never did anything. Don't use it. Also I have submitted a
patch upstream to remove the corresponding option from blockdev.
See RHBZ#1002825 for an explanation of why this call was always
useless.
Thanks: Masayoshi Mizuma
This commit adds an optional 'cachemode' parameter to the 'add_drive'
API to control caching. This corresponds approximately to the
'-drive ...,cache=' parameter in qemu, but the choices are much more
restrictive, just 'writeback' or 'unsafe', for reasons outlined below.
The caching modes supported by recent QEMU are:
writeback:
- Reports data writes completed when data is present in the host
page cache.
Only safe provided guest correctly issues flush operations.
writethrough:
- Reports data writes completed only when each write has been
flushed to disk. Performance is reported as not good.
none:
- Uses O_DIRECT (avoids all interaction with host cache), but does
not ensure every write is flushed to disk.
Only safe provided guest correctly issues flush operations.
directsync:
- Uses O_DIRECT (avoids all interaction with host cache), and
ensures every write has been flushed to disk.
unsafe:
- No special handling.
Since the libguestfs appliance kernel always issues flush operations
(eg. for filesystem journalling and for sync) the following modes can
be ignored: 'directsync', 'writethrough'.
That leaves 'writeback', 'none' and 'unsafe'. However 'none' is both
a constant source of pain (RHBZ#994517), is inefficient because it
doesn't use the host cache, and does not give us any safety guarantees
over and above 'writeback'. Therefore we should ignore 'none'.
This leaves 'writeback' (safe) and 'unsafe' (fast, useful for scratch
disks), which is what we implement in this patch.
Note that the previous behaviour was to use 'none' if possible, else
to use 'writeback'. The new behaviour is to use 'writeback' only
which is (in safety terms) equivalent to 'none', and also faster and
less painful (RHBZ#994517).
This patch also allows you to specify a cache mode for network drives
which also previously defaulted to 'writeback'.
There is a considerable performance benefit to using unsafe (for
scratch disks only, of course). The C API tests only use scratch
disks (since they are just tests, the final state of the disk doesn't
matter), and this decreases total run time from 202 seconds to 163
seconds, about 25% faster.
This adds simple support for reading the journal files from guests
that use the systemd journal.
The new APIs are:
journal-open
journal-close
journal-next
journal-skip
journal-get
journal-get-data-threshold
journal-set-data-threshold
internal-journal-get
More complex journal support (eg. for seeking within the journal,
support for cursors) could be added later.
Implement 'set-label' for XFS filesystems.
Fix the call for btrfs. Previous
commit d5817537fa added some bogus
documentation implying this call would work for btrfs, but it did
not.
Add tests.
By specifying a cleanup function we can ensure that Augeas and hivex
functions can be tested.
There is no functional change here, verified by diffing the generated
file tests/c-api/tests.c before and after.
This adds an extra optional boolean 'followsymlinks' flag to those 6
is-* APIs. If the flag is true, then symlinks are followed, ie. we
use stat instead of lstat in the test.
For the rationale behind this change, see:
https://bugzilla.redhat.com/show_bug.cgi?id=974489
- Don't use fixed names for the disks. This will allow us to
parallelize this test.
- Add a new "GETKEY:<key>" String parameter which can retrieve keys
from the handle. The temporary disk names are stored as keys.
- Don't test the close callback. However this uses the close callback
mechanism to delete the temporary disks, and in any case close
callbacks are well tested by the language binding tests.
- The generated code now produces a static array of tests (instead of
a 'perform_tests' function), making it possible to parallelize.
Since tests involving FileIn will often wish to read from local files,
it makes sense that they would want to open files in $srcdir.
Therefore allow such paths to be prefixed by "$srcdir" which is
substituted at run time by the same named environment variable (set by
automake).
This fixes separated builds in tests/c-api directory.
The previous test for grub-install hard-coded /dev/vda (ie. assuming
virtio-blk instead of more modern virtio-scsi).
This changes the test to hard-code /dev/sda instead. However this
change is still not correct since /dev/sda will be adjusted by block
device name translation in the call to grub-install, but not what is
written to /boot/grub/device.map.
Since we no longer support grub-install on Fedora, this won't affect
things, but Ubuntu still has a 'grub-install' command (although it's
actually from grub2).
This adds helper C functions 'is_string_list' and 'is_device_list'
allowing these tests to be carried out in generic C code instead of as
specialized tests.
