Soon only the virt-p2v authors will be available, so remove all the
other roles. This leaves only in the virt-p2v about dialog, which is a
mild regression compared to the current situation, although it is just
for user information.
Move (or copy the general ones) all the p2v entries in the top-level
.gitignore file to a new file specific for p2v. This will make it
easier to keep them when splitting p2v.
Copy from generator/p2v_config.ml also the bits for POD documentation,
adding them to generate-p2v-config.pl; this way,
virt-p2v-kernel-config.pod can be generated at build time directly,
instead of statically shipped as generator output.
Instead of generating the p2v kernel config using the OCaml generator,
create a Perl script to do this job, mostly at build time. This is done
to rely less on the generator for p2v, and because the generation of
these sources is quick enough that it can be done at build time (instead
of shipping the generated sources in dist tarballs).
The generate-p2v-config.pl mimics what generator/p2v_config.ml --
namings, and general structure are kept close to that for comparison.
The two C sources are created at build time by the script; however, the
p2v-config.h header is generated at configure time: this is done because
p2v-config.h is included by p2v.h (another header), which in turn is
included by all the p2v C sources -- automake is not able to properly
resolve the dependency, and thus it would not be generated properly.
Python 3.8 no longer links C extensions to -lpython, instead relying
on the fact that the python binary itself already contains those
symbols. This means $PYTHON_LIBS is empty and so the Python bindings
are not built.
Use a different test to see if the python module is available.
This way no non-namespaced OCaml C symbols are used, reducing the risk
of clashes with other code.
The only exception is ocaml-augeas, which does not build with
CAML_NAME_SPACE; it will be fixed upstream, and it affects only
ocaml-augeas itself.
While svirt_t can be used for sockets it does not always guarantee that it will
be accessible from a virtual machine. The VM might be running under svirt_tcg_t
context which will need a svirt_tcg_t label on the socket in order to access it.
There is, however, another label, svirt_socket_t, which is accessible from
virt_domain:
# sesearch -A -s svirt_t -c unix_stream_socket -p connectto
...
allow virt_domain svirt_socket_t:unix_stream_socket { ... connectto ... };
...
And virt_domain is a type attribute of both svirt_t and svirt_tcg_t:
# seinfo -x -a virt_domain
Type Attributes: 1
attribute virt_domain;
svirt_t
svirt_tcg_t
Resolves: https://bugzilla.redhat.com/1698437
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
It seems that on older Python 3 versions importlib.util is not imported
automatically when importlib is imported; as solution, import
importlib.util directly (as it is what is used, anyway).
Fixes commit f79129b8dc.
Previously, is_custom_hv() used to compare the QEMU executable found
during configure to the hypervisor set to check whether it is a custom
one; however, the QEMU found at configure time can be different than
what libvirt was configured with.
This fixes the libvirt backend when libguestfs is configured with a
different QEMU, that now will be specified as emulator overriding the
libvirt one.
We ship our own copy of it, so we do not need the external version.
(Also, the latest upstream version of ocaml-libvirt was already not
usable to build the test harness of v2v.)
Now that we have a proper libvirt connection object, use it directly to
refresh the storage pool, and define the final guest. This avoids
spawning a new virsh process twice, with no possibility to even share a
possible authentication required.
Store the Libvirt.Connect.t object as instance variable, so it can be
used also outside of prepare_targets. Use a private method to access
it, so there is no need to directly use the Lazy object.
Currently virt-v2v has few custom C-based functions for libvirt
operations, which are limited in what they do, and there is a lot of
duplicated code.
Instead, switch to ocaml-libvirt for all the libvirt interaction
currently done by the Libvirt_utils module. This has few advantages:
- each input & output module now opens a libvirt connection only once,
only when needed
- no need to pass URIs and passwords around, if not needed
- a wider range of libvirt APIs can now be used, with no need to create
bindings manually
The hierarchy of input_libvirt* classes is changed to take a Lazy object
with the libvirt connection, accessing it through a "proctected" method:
this way, the connection is opened only at the first access.
Also, the Libvirt_utils module now is just helpers around the Libvirt
module, to centralize error handling, and few common operations.
Add a copy of the libvirt-ocaml library, currently available at:
https://libvirt.org/git/?p=libvirt-ocaml.git;a=summary
This is a snapshot at commit d3ed8dcf1b0a6a8a855ceecbe0bb97f21e6665e3,
which has all the features we need (and that builds fine).
It is expected to stay synchronized with upstream, until there is a new
upstream release, and it will be widespread enough.
While there are input modes that do not use libvirt, making libvirt
mandatory for virt-v2v slightly simplifies the code now, and allow for
further improvements/integration with libvirt later on.
Adapt make-fedora-img.pl to not use deprecated APIs anymore:
- set_e2uuid -> set_uuid
- txz_in -> tar_in + compress:xz
This causes no changes in the generated test images.
Since we already assume Python >= 2.7, modernize this example to make it
work also on Python 3:
- use print() as function
- sort the mount points using a key for sorted(), instead of a
comparison function
- remove extra newline escape
- reident two lines according to the PEP 8 style
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>
This is not quite a neutral refactoring, because it means we now run
the getenforce command every time virt-v2v starts up. However it's a
trivial command that reads a single /sys file and it can't fail even
if the command is missing or on platforms that know nothing about
SELinux.
virt-v2v obviously cannot convert this kind of devices, since they are
specific to the host of the hypervisor. Thus, emit a warning about the
presence of direct network interfaces, so at least this can be noticed
when converting a guest.
