Previously this output method was almost completely untested.
This commit adds a fake ovirtsdk4 module so we can test the
-o rhv-upload method fairly completely without needing an actual
oVirt instance around.
Thanks: Pino Toscano.
For real imageio servers the destination will always be https. This
change has no effect there.
However when testing we want to use an http server for simplicity. As
there is no certificate or cafile in this case the call to create the
context will fail.
This also simplifies creation of the context object and recognizes the
"insecure" flag for connecting to imageio.
Thanks: Nir Soffer.
Since Linux commit f663b5b38fff trimming vfat is now supported by
Linux. This broke the test which assumed it was not supported. Use
another filesystem (minix) which does not support trimming instead.
Thanks: Daniel P. Berrangé and Pino Toscano.
When using the direct backend, you should see the result of testing
the qemu binary for the availability of KVM:
libguestfs: qemu KVM: enabled
Thanks: Andrea Bolognani.
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.
OCaml has a small runtime which is statically linked into the virt
tools (providing things like GC and primitives). Since OCaml 4.03 it
has been possible to select variants of this runtime, one of which is
compiled with -fPIC, using ‘ocamlopt -runtime-variant _pic’.
This has performance implications on i686, but is relatively free on
other architectures. Since it (in theory) adds to the security of the
final binary this commit enables it whenever it is available.
The majority of the tools have already options (--echo-keys &
--keys-from-stdin) to deal with LUKS credentials, although there is no
way to automatically provide credentials. --keys-from-stdin is
suboptimal, because it is a usable solution only when there is just one
device to open, and no other input passed via stdin to the tool (like
the commands for guestfish).
To overcome this limitation, introduce a new --key option in tools:
* --key /dev/device:file:/filename/with/key
* --key /dev/device:string:the-actual-key
this way it is possible to pass all the credentials needed for the
specific devices to open, with no risk of conflict with stdin, and also
in a secure way (when using the "file" way).
On the technical side: this adds a new "key_store" API for the C tools,
making sure it is used only when needed. Partially mirror it also for
the OCaml tools, although there will be a conversion to the C API
because the decryption helpers used are in the common C parts.
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.
As with the previous commit this requires that Windows guests have
been created first using the procedure from:
https://rwmj.wordpress.com/2018/09/13/creating-windows-templates-for-virt-builder/
For me:
PASS: test-v2v-conversion-of-windows-6.3-server.sh
PASS: test-v2v-conversion-of-windows-6.2-server.sh
PASS: test-v2v-conversion-of-windows-10.0-server.sh
If you don't have these templates in virt-builder then the tests will
skip.
This requires that Windows guests have been created using the
procedure outlined here:
https://rwmj.wordpress.com/2018/09/13/creating-windows-templates-for-virt-builder/
For me:
PASS: test-firstboot-windows-6.2-server.sh
PASS: test-firstboot-windows-6.3-server.sh
PASS: test-firstboot-windows-10.0-server.sh
An incidental change is that we dump the firstboot log from the guest
(even on success). If the firstboot fails this is very useful for
determining the real cause.
In nbdkit >= 1.7.2, nbdkit vddk --dump-plugin will print the shared
library name in normal output, which breaks this test.
The actual error when LD_LIBRARY_PATH is not set includes this line:
nbdkit: error: libvixDiskLib.so.6: cannot open shared object file: No such file or directory
so search instead for the error message "cannot open shared object file".
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.
Inspection code checks /etc/mdadm.conf to map MD device paths listed in
mdadm.conf to MD device paths in the guestfs appliance. However on some
operating systems (e.g. Ubuntu) mdadm.conf has alternative location:
/etc/mdadm/mdadm.conf.
This patch consider an alternative location of mdadm.conf as well.
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.
Straightforward refactoring. Apart from small modifications to clean
up the code and reorder the properties more logically there should be
no functional change.
See:
https://bugzilla.redhat.com/show_bug.cgi?id=1584678#c15
Fixes commit bcdbe6405c. However this
bug was copied directly from old virt-v2v which did the same thing
(from lib/Sys/VirtConvert/Converter/Windows.pm):
echo installing rhev-apt >>log.txt
"rhev-apt.exe" /S /v /qn >>log.txt
Thanks: Lev Veyde
With python 3, we have a nicer way to handle socket.error with errno set
to EPIPE (or ESHUTDOWN).
This is also more correct since in some cases (that I could not
reproduce yet with v2v), using e[0] with BrokenPipeError will fail with:
>>> OSError(errno.EPIPE, "Broken pipe")[0]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'BrokenPipeError' object is not subscriptable
For python 2 e[0] seems to work, but is leftover from historic python
version that used to raise a tuple instead of socket.error instance.
In python 2.7 library code e.args[0] is used. If we ever port this to
python 2 this is the best form.
This option prints the estimated size of the data that will be copied
from the source disk.
Currently this overestimates by the size of the qcow2 header, but for
real disk images that doesn't matter much.
For example:
$ virt-builder fedora-27
$ virt-v2v -i disk fedora-27.img -o null --print-estimate
[...]
virt-v2v: This guest has virtio drivers installed.
[ 44.0] Mapping filesystem data to avoid copying unused and blank areas
[ 44.5] Closing the overlay
disk 1: 1047920640
total: 1047920640
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.
