Remove the configure-time QEMU definition. No longer initialize g->hv
= QEMU. g->hv may now be NULL if the user does not explicitly either
call guestfs_set_hv or set LIBGUESTFS_HV.
Remove any assumptions in the code that g->hv is always non-NULL.
Fix one test that relied on the QEMU definition.
Commit f7a24b2ea8 ("lib/qemu.c: Use machine type none when inspecting
QMP properties") changed the number of command line parameters used
before the '-qmp stdio' option when libguestfs queries qemu features.
This broke some tests which rely on the exact order of parameters.
Fixes: commit f7a24b2ea8
Updates: commit 5da8102f5f
The existing code had a bug which you can demonstrate by doing:
$ guestfish -N fs:btrfs:10G -m /dev/sda1 \
btrfs-subvolume-create /sub :
btrfs-subvolume-snapshot /sub /snap1 : \
btrfs-subvolume-snapshot /sub /snap123 : \
btrfs-subvolume-snapshot /sub /snap123456 : \
btrfs-subvolume-show /sub
...
libguestfs: error: appliance closed the connection unexpectedly.
This usually means the libguestfs appliance crashed.
As the code for parsing the output and creating the comma-separated
list of snapshots was unncessarily complicated in the first place,
simplify it. This also fixes the bug.
This also adds a regression test.
Thanks: Arye Yurkovsky
Link: https://lists.libguestfs.org/archives/list/guestfs@lists.libguestfs.org/thread/QV5VDHIH7WRUNAE54K6OEOKJMWL6M7EM/
It tests a corner case that we don't experience in real life (although
it can happen). Moreover the test often hangs, so we're not proving
anything except that there's a very obscure bug that we haven't fixed
and probably won't ever fix.
Part of this test uses `qemu-nbd -k SOCKPATH`, and passes
that socket to libvirt. SOCKPATH will have label user_home_t,
which svirt_t can't access, so running with selinux enforcing this
test will always fail.
Manually change the socket label to svirt_image_t which makes
selinux happy.
Note: libvirt does not relabel most (all?) externally managed socket
paths. I think this is correct, since in theory this could be a
socket shared with other processes, so its up to the user to ensure
DAC/MAC permissions are acceptable for their usecase.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
really what we need is sgdisk in the appliance, but for test suite
purposes this check is enough IMO
Signed-off-by: Cole Robinson <crobinso@redhat.com>
On RHEL 10.2 aarch64 (only) we see:
$ echo '{ "execute": "qmp_capabilities" }' '{ "execute": "query-kvm" }' '{ "execute": "quit" }' | QEMU_AUDIO_DRV=none "/usr/libexec/qemu-kvm" -display none -machine "virt,accel=kvm:hvf:tcg" -qmp stdio
qemu-kvm: invalid accelerator hvf
qemu-kvm: falling back to KVM
{"QMP": {"version": {"qemu": {"micro": 0, "minor": 1, "major": 9}, "package": "qemu-kvm-9.1.0-15.el10_0.4"}, "capabilities": ["oob"]}}
qemu-kvm: warning: CPU model cortex-a57-arm-cpu is deprecated -- use 'host' / 'max'
qemu-kvm: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
Unfortunately we cannot use guestfs_int_get_cpu_model (as that
requires us to already know if KVM is supported), so we just have to
guess that -cpu max will work, at least enough for QMP to work.
Fixes: https://issues.redhat.com/browse/RHEL-121076
Reported-by: Xiang Hua Chen
test-parallel-mount-local reliably fails when my machines are
under load (like running the test suite in parallel). The
issue is /usr/libexec/gvfs-udisks2-volume-monitor fiddling with
the fuse mounts, preventing them from being unmounted.
./fuse/guestunmount defaults to 5 unmount retries with increasing
time backoff, but apparently that isn't enough. Bumping it to
use 10 retries makes things more reliable for me.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Previously we tested if KVM was available, and cached that for the
qemu binary. I think this was actually wrong. For example, if the
machine restarts, then the cache is still around, but KVM might be
enabled or disabled because of a new host kernel.
In any case, let's radically simplify this.
Test for KVM on each run. Consequently we can remove all the qemu
test caching stuff as it is no longer used anywhere.
I also tightened up the code that runs the QMP query-kvm command, so
now any unexpected output will cause a runtime failure. This command
ought to work, and if it breaks we ought to know about it and fix it.
This was a test for a 13 year old problem to do with problems
launching libguestfs appliances in parallel. That problem does not
affect current code.
Testing build/launch of libguestfs appliances is a valuable thing to
test. However we start libguestfs in parallel in both the current
test suite and in higher level tools, and this test was dubious (and
breaks with recent changes). Therefore remove the test.
The guestfs_selinux_relabel function was very hard to use. In
particular it didn't just do an SELinux relabel as you might expect.
Instead you have to write a whole bunch of code around it (example[1])
to make it useful.
Another problem is that it doesn't let you pass multiple paths to the
setfiles command, but the command itself does permit that (and, as it
turns out, will require it). There is no backwards compatible way to
extend the existing definition to allow a list parameter without
breaking API.
So deprecate guestfs_selinux_relabel. Reimplement it as
guestfs_setfiles. The new function is basically the same as the old
one, but allows you to pass a list of paths. The old function calls
the new function with a single path parameter.
[1] https://github.com/libguestfs/libguestfs-common/blob/master/mlcustomize/SELinux_relabel.ml
This test has never been run. It was originally added in
commit 36d6df671e ("tests/http: Add a test of HTTP protocol.", 2013).
However even when it was added, it was commented out.
Updates: commit 36d6df671e
These APIs allow you to capture output from guest commands that
generate more output than the protocol limit allows.
Thanks: Nijin Ashok
Fixes: https://issues.redhat.com/browse/RHEL-80159
tests/Makefile.am assumes the test image is located in
tests/syslinux/, but we actually created it in tests/. Fix the
location, and also ensure the test will clean it up after running
successfully.
Replace strange $TEST_FUNCTIONS variable/expansion thing with
something more like what we use in nbdkit, a simple tests/functions.sh
script that gets sourced into each test script.
Update the common submodule to get:
commit 8137d47d0e654065391151eb275e3b64f230f6f5
Author: Richard W.M. Jones <rjones@redhat.com>
Date: Thu Feb 13 11:13:55 2025 +0000
mlcustomize, mltools: Replace $TEST_FUNCTIONS
TEST_FUNCTIONS is being removed from libguestfs and guestfs-tools (it
was removed from virt-v2v a while back). Make the same adjustment in
the common submodule.
(and some other commits which are not relevant to libguestfs)
Run this command across the source:
perl -pi.bak -e 's/(20[012][0-9])-20[12][012]/$1-2023/g' `git ls-files`
and remove changes to po{,-docs}/*.po{,t} (these will be regenerated
later when we run 'make dist').
It might be left over from a previous failed run. Best to unlink the
old file before starting qemu-nbd, so there's no possibility of
getting confused later when we wait for the file to appear.
This test fails for reasons I have not fully understood yet. However
one thing I noticed is that the Unix domain socket and PID file used
the tests are placed in the tests/ directory, not the tests/nbd/
subdirectory, so let's fix that:
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -p 63668 ...
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -p 60684 ...
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -k /home/rjones/d/libguestfs-rhel-9.2/tests/unix.sock ...
Fixes: commit 6d32773e81
Test fails as it cannot find .xml file. Turns out $pwd=./tests and
and not ./tests/regressions as supposed in script.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@openvz.org>
Test fails as it cannot find .in file. Turns out $srcdir=. (which is ./tests) and
and not ./tests/regressions as supposed in script. Same apply to
$abs_srcdir.
Also put .out file in ./tests/regressions too.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@openvz.org>
This was a feature that allowed you to add drives to the appliance
after launching it. It was complicated to implement, and only worked
for the libvirt backend (not "direct", which is the default backend).
It also turned out to be a bad idea. The original concept was that
appliance creation was slow, so to examine multiple guests you should
launch the handle once then hot-add the disks from each guest in turn
to manipulate them. However this is terrible from a security point of
view, especially for multi-tenant, because the drives from one guest
might compromise the appliance and thus the filesystems/drives from
subsequent guests.
It also turns out that hotplugging is very slow. Nowadays appliance
creation should be faster than hotplugging.
The main use case for this was virt-df, but virt-df no longer uses it
after we discovered the problems outlined above.
These APIs were an experimental feature for passing through 9p
filesystems from the host to the libguestfs appliance. It was never
possible to use this without hacking the qemu command line of the
appliance to add such drives by hand. It also didn't fit the
libguestfs model very well. And 9p is generally deprecated in
upstream qemu.
Note that for ABI reasons these APIs are not actually removed, they
have been changed so that they always return an error. These APIs
were actually hard-removed from all versions of RHEL.
See-also: https://bugzilla.redhat.com/921710
User-Mode Linux was an alternative hypervisor that could run the
appliance, instead of using qemu. It had many limitations including
lack of network, and UML support in Linux has been semi-broken for a
long time. It was also slower than KVM on baremeal in general and had
various corner cases which were much slower including the emulated
serial port which made bulk uploads and downloads painful. Also of
course it lacked qemu-specific features like qcow2 or any
network-backed disk, so many disk images could not be opened this way.
This was never supported in RHEL.
See-also: https://bugzilla.redhat.com/1144197
This experimental feature allowed you (in theory) to connect to an
existing instance of the libguestfs daemon. (Again, in theory) it
allowed you to attach to running guests. This didn't work well in
practice. If you want to do this, install qemu-guest-agent inside
your guest instead.
This also disables the --live options in guestfish and guestmount.
(The option now prints an error).
This was never supported in RHEL.
The daemon tests relied on this connection method to perform tests on
a bare daemon, so this removes those tests. They were not especially
valuable.
See-also: https://bugzilla.redhat.com/798980
Commit 6d32773e81 ("tests: Run the tests in parallel.") makes all of
the tests run in the same directory. Previously tests expected to be
run in their own subdirectories and so were freer about using generic
filenames. When run in parallel these filenames now clash. Fix
another case.
Fixes: commit 6d32773e81
Commit 6d32773e81 ("tests: Run the tests in parallel.") combined
multiple Makefiles into one. During this conversion I accidentally
made several mistakes - duplicating the EXTRA_DIST entry for
mountable/test-mountable-inspect.sh and omitting the backslash
continuation of the TESTS line.
Fixes: commit 6d32773e81
Create a new (fake) Fedora disk image with two partitions. /dev/sda1 is
the boot partition as usual, /dev/sda2 is used as an LVM PV. The VG has
four LVs, Root and LV1 through LV3.
Each LV holds a LUKS device (with a different key). Each decrypted LUKS
device holds an ext2 filesystem, with "/dev/mapper/Root-luks" holding the
root filesystem.
Each filesystem has a dedicated label (ROOT, LV1, LV2, LV3).
In the test case, run guestfish in inspector mode, twice.
In the first invocation, provide the LUKS passphrases by LV name. Also
specific to the first invocation, fetch the LUKS UUIDs by LV name.
In the second invocation, provide the LUKS passphrases by UUID.
In both invocations, after decryption, check the filesystem labels, the
/dev/mapper/* names generated for the decrypted LUKS block devices, and
the existence of "/etc/fedora-release" on the root filesystem.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1658126
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220223162120.16729-3-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
