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 fixes the handling of paths for the protocols named above, with
respect to leading '/' (or not) on the volume/export name.
See previous commits which did the same fixes for Ceph:
commit 53a3ff9c00
commit 992a6b2970
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.
The path at the protocol level is:
pool/disk
(with no leading '/' character). This is now what you have to pass to
guestfs_add_drive_opts.
Also Ceph can be called with no explicit servers (it uses the contents
of /etc/ceph/ceph.conf instead). So allow zero servers to be used.
Because EXTRA_DIST simply used $(TESTS), and because the list of tests
includes C binaries, these were included in the tarball (actually not
binaries, but libtool scripts, but it's still undesirable).
tests/nbd/test-nbd.pl contains a hack (a call to sleep) to wait
for qemu-nbd to start up in another process.
This sleep was previously located before the call to $g->launch()
since that is where (previous to commit 4a0f5ed382) the backend would
have connected to the NBD server.
However in the new code, an initial NBD connection test is done when
the drive is added (ie. $g->add_drive (..., protocol=>"nbd")), which
duly failed intermittently because the qemu-nbd server had not opened
its socket yet.
Move the wait earlier -- just after the fork -- to avoid this.
This updates commit 4a0f5ed382.
In some places we turn relative paths passed by the caller into
absolute paths: for example in the libvirt backend, all relative paths
to disk images have to be turned into absolute paths (by calling
realpath) because otherwise libvirt doesn't work.
This has the potential to break things, especially considering that
qemu uses the path passed to it in order to resolve the relative paths
of backing files.
For example consider the case where 'overlay' is a symbolic link to
/dev/dm-1, but /dev/dm-1 contains a qcow2 which references './backing'
as its backing file. If we rewrote 'overlay' to '/dev/dm-1', then
qemu would try to look up '/dev/backing' for the backing file and
fail.
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1053684https://www.redhat.com/archives/libguestfs/2014-January/thread.html#00087
This means there will be no default hypervisor, and effectively the
user will always have to specify one (eg. by setting LIBGUESTFS_HV or
calling guestfs_set_hv).
This is useful on platforms where qemu doesn't work, or where qemu is
not needed (eg. if you want to use UML, or you just want to compile
libguestfs without using/testing it).
Added in 2392fae680 and removed in
be025369ad622867ecf08d5c9170e8e59d2d6294; now they should work with any
backend, as the device names are normalised and not change the guestfish
output depending on the used backend.
Thanks Richard for the hints.
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.
Although this test only specifically tests the direct backend, the
same code is shared with the libvirt backend in some circumstances
(eg. creating readonly drives). So this is testing a bit of both.
Since this is essential for security, be much more proactive about
trying to create a random seed file, even for guests which have buggy
installers that don't create this file during installation.
qemu-system-ppc64 lets you add the IDE interface to the appliance, but
the appliance kernel ignores it (and consequently can't find the
appliance disk so it all goes wrong). Best to just disallow this.
Also skip tests that try using iface = 'ide'.
ARM doesn't support IDE. (Well, that's not entirely true as I found a
reference to one extremely obscure ARM board that had IDE disks, but
qemu-system-arm doesn't appear to support them).
