After the proposed split of the libguestfs repo, we will end up with
the following layout:
libguestfs.git
common -> git submodule libguestfs-common.git
generator
virt-v2v.git
common -> git submodule libguestfs-common.git
guestfs-tools.git
common -> git submodule libguestfs-common.git
The generator will only be able to write to libguestfs directories and
the common directory/submodule. This is mostly the case already with
only 6 exceptions:
customize/customize-options.pod
customize/customize-synopsis.pod
customize/customize_cmdline.ml
customize/customize_cmdline.mli
v2v/uefi.ml
v2v/uefi.mli
This commit moves these files around so they appear under common/ml*
It is somewhat unsatisfactory because it involves copying files
around, but there are some mitigating factors:
(1) Any changes now give us more freedom to develop faster and thus
clean things up in future.
(2) The v2v/uefi files ought to go away in future anyway.
This is simple code motion and should have no effect on the built
programs or tests.
These two modules are a dependency of virt-v2v. Since we intend to
split virt-v2v from the other OCaml virt-* programs, we cannot have a
dependency between virt-v2v and virt-customize. Instead we must move
the modules to a common directory (common/mlcustomize) and have both
tools depending on the modules from there.
This is simple refactoring and should not affect how the programs work
or are tested.
By default the installer will set the hostname to what the DHCP returns,
exposing details of the machine where make-template.ml runs.
Instead, force "unassigned-hostname.unassigned-domain" as hostname, so
plays nicely with the hostname setting code in virt-customize.
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.
builder.libguestfs.org has almost run out of space. I would like to
move templates for older guests to the archive site (which is slower
but has unlimited space). The easiest way to do this is to add a
second repo.
This only affects obsolete/unsupported Fedora releases.
For a while libguestfs.org/builder has redirected to
builder.libguestfs.org. This change just makes virt-builder go direct
to the subsite instead of via the redirect.
This option was removed from qemu for no apparent reason except to
break existing consumers. It does the same as -no-user-config, added
in May 2012, so use that instead.
I think libvirt or virt-install has changed recently so that it
creates disk images which are not public readable. This has lead to
me uploading two sets of non-readable templates for virt-builder. Set
the mode explicitly to 0644.
Thanks: Laine Stump, Jacob Shivers.
After this commit, all annocheck errors are fixed except for:
Hardened: virt-get-kernel: MAYB: Gaps were detected in the annobin coverage. Run with -v to list.
After discussion with the annocheck maintainers this gap in coverage
(which corresponds to the OCaml runtime) seems to be caused either by
the runtime not being linked with the right flags, or might be a bug
in annocheck itself. In any case it's not something that can be
resolved within the scope of libguestfs.
Instead of returning directly a Getopt.t handle, now
Tools_utils.create_standard_options returns a struct, which at the
moment contains only the Getopt.t handle. This way, it will be easy to
add more data needed for handling standard command line options.
This is mostly refactoring, with no functional changes.
Provides support for building:
- Windows 7
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
Note that these images cannot be released to the public because of
obvious licensing issues. But this documents how we build them for
internal consumption so that others can also build them.
Thanks: Christophe Fergeau, Tomáš Golembiovský.
virt-sparsify in copying mode takes a huge amount of temporary space
and takes a very long time. In any case it's not really necessary for
modern guests since in-place sparsification is fully supported now.
This function will soon be used to generate Windows unattended.xml
files (as well as Debian preseed) so just rename it back to
‘make_kickstart’ rather than attempting to explain in the name every
way it could be used.
Really use the parameter of the "read_file" function, instead of
hardcoding "out". This does not change the behaviour, since all the
callers already use "out" as the file name to read.
Fixes commit 7e3689bfe0.
Add an optional argument for --machine-readable to select the output,
adding a new function to specifically write data to that output stream.
The possible choices are:
* --machine-readable: to stdout, like before
* --machine-readable=file:name-of-file: to the specified file
* --machine-readable=stream:stdout: explicitly to stdout
* --machine-readable=stream:stderr: explicitly to stderr
Adapt all the OCaml-based tools to use the new function, so the
--machine-readable choice is respected.
It was convenient to have these as separate variants when we were only
using this type to generate JSON. However if we also use it to parse
JSON documents then integers in the document should only map to a
single variant.
Commit bd1c5c9f4d changed all the code
to use Jansson instead of yajl. However it didn't change the OCaml
module name (still Yajl).
This commit changes the module to a neutral name ("JSON_parser") and
moves it into common/mltools so it can be used by other tools.
This leaves us in a slightly awkward situation of having two JSON-ish
OCaml modules (JSON for creating trees and JSON_parser for parsing
them) with incompatible types. That is left for future work to
resolve. (It should be easier to do now that both modules live in the
same directory.)
This is just renaming and general refactoring. There should be no
change in functionality.
Make use of the helper provided by Tools_utils.create_standard_options,
so there is no need to implement the logic in each tool.
This affects all the OCaml tools with --machine-readable, namely:
virt-builder, virt-builder-repository, virt-dib, virt-get-kernel,
virt-resize, virt-sparsify, and virt-v2v.
These are file descriptors, not the high level OCaml in_channel/
out_channel type, so we would normally not refer to them as *_chan.
Just renaming, no functional change.