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.
Starting with 5.2.0, libvirt has a way to select automatically the
firmware for a guest using an attribute of the <os> tag. Hence, use
this information (when available, of course) to flag the firmware used
by the guest.
Return the right osinfo short IDs for some rolling Linux distributions,
such as Arch Linux, Gentoo, and Void Linux. Their IDs were recently
added to osinfo-db.
Consider Arch Linux as rolling distribution, so it is recognized using
/etc/os-release.
The end result does not change, although this makes Arch Linux inspected
using os-release only, instead of getting inspection details mixed from
both os-release and lsb-release.
Add "gentoo" as recognized ID in /etc/os-release, and consider it as
rolling distribution (so without VERSION_ID in os-release).
This avoids using a not-useful version read from /etc/gentoo-release,
e.g. "Gentoo Base System release 2.6".
Use a static list of rolling distros, so it is easier to handle them
differently; use this list for handling the lack of VERSION_ID in
os-release files.
This is just refactoring, no behaviour changes.
Add a new output mode to virt-v2v: similar to -o local, the written
metadata is a JSON file with the majority of the data that virt-v2v
knowns about (or collects) during the conversion.
This is meant to be used only when no existing output mode is usable,
and a guest needs to be converted to run on KVM anyway. The user of
this mode is supposed to use all the data in the JSON, as they contain
important details on how even run the guest (e.g. w.r.t. firmware,
drivers of disks/NICs, etc).
When the machine readable mode is enabled, print all the messages
(progress, info, warning, and errors) also as JSON in the machine
readable stream: this way, users can easily parse the status of the
OCaml tool, and report that back.
The formatting of the current date time into the RFC 3999 format is done
in C, because of the lack of OCaml APIs for this.
Allow to specify a file descriptor for the machine readable output.
Use the same assumption as done in v2v, i.e. that Unix.file_descr is
simply the int file descriptor.
Enhance the helper printf function for machine readable output to always
flush after each string: this way, readers of the machine readable
stream can get the output as soon as it is outputted.
Store log from MSI installer. Log file will be located in firstboot
scripts-done directory with name rhev-apt.log. The path has to be
double-quoted to handle spaces in path name properly.
Hopefully this can help resolve RHBZ#1584678 someday.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
The debug message was slightly changed too to better match the similar
message for ISO case. It refers to the root directory instead of the
specific subdirectory inside guest tools.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
The RHV Tools ISO is provided as Red Hat only product, and thus not
available for all the virt-v2v users. Hence, change the way we report
the status of the installation of the qemu guest agent from the RHV
Tools ISO:
- do not warn if virt-v2v does not know how to install the package for
the current guest
- do not warn if the ISO does not contain packages for the current guest
- on successful installations, show an info message
Related: RHBZ#1691659
Right now the code copies, and then tries to install, all the files
found for the directory of a distro. This does not take into account
differences in the architectures of the packages available, so a x86_64
package must be installed only on x86_64 guests.
As solution, filter the packages using the typical suffix used by
packages (so architecture + file extension), to pick only packages
compatible with the current guest.
