This brings libguestfs into line with other projects which have a
separate include/ directory for the public header.
It's also the case that <guestfs.h> has never particularly belonged in
the lib/ subdirectory. Some tools add -Ilib/ but they only need
<guestfs.h> and not any other headers from that directory, and
separating out the public header allows us to clean those up. This is
certainly the case for examples, and some language bindings and some
tests.
In future I'm hopeful we can use this as the basis to tease out other
dependencies, as a prelude to separating them out from the repo.
Although it's highly unlikely in normal use, while testing device name
translation patches it did happen and caused the test to segfault
instead of exiting with an error.
Nowadays there are hard drives and operating systems which support
"4K native" sector size. In this mode physical and logical block size
exposed to the operating system is equal to 4096 bytes.
GPT partition table (as a known example) being created in this mode will
place GPT header at LBA1 which is 4096 bytes. libguetfs is unable to
recognize partition table on such physical block devices or disk images.
The reason is that libguestfs appliance will look for a GPT header at
LBA1 which is seen at 512 byte offset.
In order to fix the issue we need a way to provide correct logical block
size for attached disks. Fortunately QEMU and libvirt already provides
a way to specify physical/logical block size per disk basis.
After discussion in a mailing list we agreed that physical block size is
rarely used and is not so important. Thus both physical and logical
block size will be set to the same value.
In this patch one more optional parameter 'blocksize' is added
to add_drive_opts API method. Valid values are 512 and 4096.
add_drive_scratch has the same optional parameter for a consistency and
testing purpose.
add-domain and add_libvirt_dom will pass logical_block_size value from
libvirt XML to add_drive_opts method.
Libvirt 6.0 now requires that every disk in the backing chain has an
explicit backing format. For example this will be rejected by
libvirt:
qemu-img create -f qcow2 -b backing-disk disk.qcow2
with the error:
Original error from libvirt: Requested operation is not valid:
format of backing image 'backing-disk' of image 'disk.qcow2' was not
specified in the image metadata (See
https://libvirt.org/kbase/backing_chains.html for troubleshooting)
[code=55 int1=-1]
Instead you have to use the -F option to specify the format, eg:
qemu-img create -f qcow2 -b backing-disk -F raw disk.qcow2
This helper script will contain variables with results of configure
checks, so other scripts can source it.
Source it automatically in test-functions.sh, so every test can already
make use of it.
xgetcwd is used only in a test, so there is no need to pull a gnulib
module just for it.
Switch to use getcwd directly with a fixed buffer: the tests would have
failed with paths longer than 992 characters, as the libvirt_uri would
have been truncated. Since there were no reports of issues, we can
assume that the current working directory will fit in 1024 characters;
adapt the size of libvirt_uri accordingly.
Add a simple way to do not even provide prototypes of deprecated
functions in the C library: this way, users (like our tools) can build
against the library making sure to not use any deprecated function, not
even when compiler deprecation warnings are disabled.
Add it to the majority of our tools/internal libraries, and make sure
that it is not defined when building the API bridges of our bindings.
Right now, deprecated functions of the library do not trigger any
compiler deprecation warning by default; they do that only if
GUESTFS_WARN_DEPRECATED=1 is defined. However, this is not something
that seems to be done often -- at least none of the projects using the
libguestfs C API does that.
Hence, do a small behaviour change to change this on the other way
round: now deprecated functions trigger compiler deprecation warnings by
default, using GUESTFS_NO_WARN_DEPRECATED to disable this (and revert
to the previous behaviour). Even though deprecated functions will not
be removed, we really want users to migrate away from them, as they were
deprecated for good reasons.
Define GUESTFS_NO_WARN_DEPRECATED where needed:
- in all the bindings, as they bind all the functions including the
deprecated ones
- in the guestfish actions, as it exposes almost all the APIs
- in the C API test, as it runs the automated tests of all the APIs that
have them
- for two tests that explicitly test deprecated functions
part-expand-gpt takes extreme cautions and doesn't proceed to writing
to the disk if the preliminary dry run of sgdisk has generated any
warnings on stdout.
This blocks the use of part-expand-gpt on disk shrink (with disk
resize being the main usecase for part-expand-gpt), because sgdisk dry
run produces a warning in that case.
So remove the excessive safety check, and leave it up to the caller.
Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
test-relabel.pl performs a full SELinux relabelling of the phony guest,
and the selinux_relabel API does not work if the "selinuxrelabel"
feature is not available.
Commit c11a92751e chose some strangely
sized partitions for testing Linux MD devices. The disks were 100M
however the four partitions only covered the first 10M of disk space
(with the rest being unallocated and unused in the test).
This worked until Linux 4.20 where the ~2M-sized partitions become too
small for a Linux MD device.
This commit changes the test to use four 20M-sized partitions which is
sufficient space to create the MD device with recent kernels. I also
modified the partition allocation code to use explicit calculations
and variables, making it considerably clearer.
Since Linux commit f663b5b38fff trimming vfat is now supported by
Linux. This broke the test which assumed it was not supported. Use
another filesystem (minix) which does not support trimming instead.
Thanks: Daniel P. Berrangé and Pino Toscano.
Extended MBR partitions cannot hold filesystems - filter them out.
RWMJ:
* Simplify is_mbr_extended function.
* Fix regression test rhbz1285847:
The test assumed that list-filesystems would return an extended MBR
partition (as "unknown"). However such partitions only contain
logical partitions inside them, not filesystems.
* Some minor whitespace changes.
Test guestfish list-filesystems command finds file system on partitioned md device and doesn't take into account md device itself (similar to as physical devices are filtered out if they are partitioned).
Newer versions of qemu use file locking for the images by default, and
apparently that does not work with /dev/null. Since this test just
calls qemu-img to get the format of an empty image, create a temporary
one instead.
While scanning the sources, some of the files (i.e. the cached
appliance) may be larger than 4G, and thus raise EOVERFLOW on 32bit
architectures.
Fixes commit b4e119d8b7.
One gnulib test creates a symlink to the same directory, causing our
iteration to read the same test directory over and over, every time
considering it as new level of subdirectory.
As solution (or workaround), when iterating through a directory consider
only regular files, and directories, ignoring any other file type
(symlinks included).
Test guestfish finds:
1. md device created from physical block device and LV,
2. md device created from LVs
3. LV created on md device
raid0 is used for md device because it is inoperable if one of its components is inaccessible so it is easy observable that md device is missing (raid1 in this case will be operable but in degraded state).
Because of vagaries in how the debug messages get printed they can get
split over lines:
gulibguestfs: trace: truncate_size = 0
estfsd: => truncate_size (0xc8) took 0.00 secs
and the code which filtered out those messages before comparison was
failing. This makes the code more liberal on how it matches and
filters out these messages.
Latest libvirt (3.8, I think) made a very small adjustment to the
format of the generated -drive parameter when using iscsi, from:
file=iscsi://1.2.3.4:1234/iqn.2003-01.org.linux-iscsi.fedora,
to:
file=iscsi://1.2.3.4:1234/iqn.2003-01.org.linux-iscsi.fedora/0,
This makes a corresponding change to the test so that both patterns
can be recognized.
Commit 0b631d739b changed the debug
message format from the main loop in guestfsd. This test tried to
filter out these messages when comparing output, but that stopped
working. The problem was only evident when enabling debugging while
running the tests.
Replace the monolithic 'test-max-disks.pl' script with a test program
written in C. The program is completely equivalent to the old script,
except for the enhancement that it is able to detect if disks are
added to the appliance in the wrong order.
The tests themselves are split out into some shell scripts:
- test-27-disks: Fully tests 27 disks.
This is the minimum supported configuration for all backends.
- test-255-disks: Fully tests 255 disks.
This is the most disks that libguestfs up to 1.36 supported.
- test-add-lots-of-disks: Add ‘a lot’ of disks and exit (without
any further testing). This is meant to try to exercise > 255
disk case but without being as slow as a test of the max number
of disks (which takes ages, even for as few as 4000 disks).
- test-max-disks: Test the maximum possible number of disks.
The maximum depends on several factors, notably which backend
is in use, and the limit on the number of open files.
‘test-max-disks’ is a slow test.
