Enable a few POD options:
- Don't generate an errata section in the output.
- Send errors and warnings to stderr.
- Die if any errors or warnings are seen while generating the outputs.
The drive used for the appliance is a raw (sparse) disk: specify that
explicitly in its -drive qemu command line options, so qemu can skip the
autodetection of its format and save a tiny bit of time.
Allow kernel options such as p2v.o=libvirt to override internal
defaults, even for GUI configuration.
The main change is to split up the kernel conversion into two steps:
reading the kernel command line configuration, and performing the
conversion. The kernel command line can then be read by the main
program and used to initialize the config structure for either kernel
conversion or GUI conversion.
A small adjustment is required in the test because p2v.pre no longer
runs before kernel command line parsing. (The aim is to have
p2v.pre/post/fail still only run when doing a kernel conversion, not
in the GUI case.)
Since we started to use the parallel tests framework in automake,
'make check-slow' has been broken. This is because parallel tests
doesn't allow you to run 'make check TESTS=...' with a set of test
scripts which do not also appear in the static list of tests in the
Makefile.am. We would like to list and run only "fast" tests in the
Makefile.am, and have other scripts for slow tests.
The solution is to add the slow tests to Makefile.am, but condition
those tests on an environment variable SLOW=1 being set.
This commit fixes all the existing slow tests in this way, and updates
the documentation (guestfs-hacking(1)) to document how slow tests
should be written in future.
Valgrind has a weird hack where it invokes a glibc function called
__libc_freeres on exit. See:
http://valgrind.org/docs/manual/faq.html#faq.exit_errors
This is intended to free up memory that glibc won't normally free
(since glibc doesn't free everything on exit for efficiency reasons).
More importantly, valgrind runs __libc_freeres even if the process
calls _exit, resulting in this bug:
https://bugs.kde.org/show_bug.cgi?id=361810
(either a bug in valgrind, or in glibc, or in both, depending on your
point of view).
In any case we don't want this behaviour, so disable it.
Also we have to add suppressions for new "leaks" in glibc found by
valgrind because __libc_freeres no longer runs. In fact there is only
one such suppression needed, for TLS allocation in multithreaded
tests.
When we are valgrinding we don't really care about the child
processes, which might be qemu, libvirtd, etc. So disable tracing
into children (at least, as far as is possible with valgrind, which is
not entirely disabling it, but suppressing it).
This is convenient because it allows you to do:
rm -f docs/C_SOURCE_FILES
make docs/C_SOURCE_FILES
if you ever wanted to recreate that file (without doing 'make dist').
Note that the rules depend on configure.ac so that the files get
updated on each new version (otherwise the files would never get
updated).
On Linux this will load the whole file into the page cache. However
the output file is empty and zero sized just after it is opened, so
this has no effect. Note that the advice is not persistent, so this
really does nothing.
I considered adding the call back after the file has been written,
just before the close, but:
- If we do a virt-resize next then we will open and read the file mostly
sequentially, so readahead will deal with any missing pages.
- If we do a virt-customize next then we will only access a small
part of the disk image, so loading it all into the page cache adds
extra work.
- In any case, since we have just written the file it's likely to
still be in the page cache.
This commit adds guestfs_int_fadvise_normal, but it's not enabled
since nothing calls it.
It also documents what Linux actually does, which is a bit different
from what I thought these settings did. Note this is for Linux 4.6.0rc3
and may change in future.
This updates commit 83e92b4a97.
Setting POSIX_FADV_RANDOM makes no measurable difference, but at least
it's the right thing to do.
POSIX_FADV_WILLNEED makes no measurable difference either.
Moving the calls to posix_fadvise to just after the open() makes no
measurable difference, but does make the code a bit clearer.
Changing POSIX_FADV_NOREUSE on the input file descriptor to
POSIX_FADV_DONTNEED slows things down by about 10%.
Add wrappers around posix_fadvise and use them in places we were
calling posix_fadvise directly before.
Also in virt-builder we were doing this (and ignoring the result):
posix_fadvise (fd, 0, 0, POSIX_FADV_RANDOM|POSIX_FADV_DONTNEED);
However the POSIX_FADV_* flags are _not_ bitmasks! In fact
POSIX_FADV_RANDOM|POSIX_FADV_DONTNEED == POSIX_FADV_NOREUSE so we were
giving a completely different hint from what we thought we were
giving.
The current implementation of getumask involves writing a file with
mode 0777 and then testing what mode was created by the kernel. This
doesn't work properly if the user set a per-mount umask (or fmask/
dmask).
This alternative method was suggested by Josh Stone. By forking, we
can use the thread-unsafe method (calling umask) and pass the result
back over a pipe.
This change also fixes another problem: mode_t is unsigned, so cannot
be used to return an error indication (ie. -1). Return a plain int
instead.
Thanks: Josh Stone, Jiri Jaburek, Eric Blake.
Exclude more files from the documented sources in C_SOURCE_FILES:
- sources generated by XDR definitions
- sources generated by gperf
- errnostring.c (generated by the generator, and copied around from src
to daemon during build)
Also update C_SOURCE_FILES as well, so libguestfs builds again from
scratch.
Virtio-SCSI offers a number of advantages over virtio-blk, in
particular, it supports SCSI UNMAP (aka trim) which is crucial for
keeping the virtual drive from wasting host disk space.
This patch adds support for virtio-scsi as the virtual disk connection
type both on input and on output of v2v.
Virtio-blk remains the default, so for now virtio-scsi-based guests can
only be produced in --in-place mode.
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
There's no particular reason that we have to update these files in
every 'make'. It's slow, and it doesn't really matter if a single
file is accidentally omitted from translations on a developer's build
machine.
On the other hand generating it from 'make dist' has advantages:
- We only do it once per release.
- The maintainer can check the changes carefully.
- If a developer adds some random files in their local build tree,
these won't be picked up accidentally.
- Changes to POTFILES etc won't leak into general commits.
Add the real list of C source files to the Makefile, instead of trying
to calculate it. This (will, in the next commit) fix a problem with
the build on Koji where we created a subdirectory (for python3/) but
the find command picked up files from that directory for the
documentation (and then failed).
This fixes commit 04229c68d6.
As in libvirt, allow internal documentation comments in C files.
These are marked using '/**' comments. Unlike libvirt which has an
ill-defined and inconsistent markup, the markup we use is Perl POD.
These comments are added to guestfs-internals(1), but are most likely
to be read in-place.
This commit changes some existing comments in src/launch.c to
demonstrate how this can be used.
Refactor registry patching to share common parts between Win <= 7 and
Win >= 8. Also branch between the two based on the presence of the
DriverDatabase subtree rather than on the OS version, which allows not
to pass the inspect handle into the functions.
OTOH make the patching functions accept the driver name and device PCI
id as arguments; this will allow to easily expand the code to support
other drivers (e.g. vioscsi) later on.
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
It turned out (by trial and error) that for Windows >= 8 / 2012, even
though the PnP system uses names related to the original driver's .inf
file for certain entries under DriverDatabase registry subtree, this
doesn't have to hold for the storage driver to make it boot.
So use our own artificial names there and simplify the surrounding code.
This will also make sure the added entries don't confilct with those
generated by PnP proper once the driver is installed, and that the
entries are easy to look up in the eventual registry.
The name chosen to refer to the driver -- "guestor" -- is intentionally
different from the original "viostor" both to avoid collisions and to
naturally expand to other relevant drivers (e.g. "vioscsi") later on.
Tested on
Win 8 x32
Win 8 x64
Win 8.1 x32
Win 8.1 x64
Win 2012R2 x64
Win 10 x64
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
The patch to the Windows registry allowing it to boot off a virtio-blk
drive was initially conceived by comparing the state with virtio-blk
driver properly installed, to that without.
However, we don't want to replicate the Windows PnP system; rather we
need to apply just enough edits to make the system boot, and then let
the Windows PnP manager figure out the rest.
It turned out (by trial and error) that for Windows >= 8 / 2012 the
"just enough" set includes only the service entry for the driver, and a
few entries under DriverDatabase.
Tested on
Win 8 x32
Win 8 x64
Win 8.1 x32
Win 8.1 x64
Win 2012R2 x64
Win 10 x64
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
The patch to the Windows registry allowing it to boot off a virtio-blk
drive was initially conceived by comparing the state with virtio-blk
driver properly installed, to that without.
However, we don't want to replicate the Windows PnP system; rather we
need to apply just enough edits to make the system boot, and then let
the Windows PnP manager figure out the rest.
It turned out that for Windows <= 7 / 2008R2 the "just enough" set
includes only the service entry for the driver, and a
CriticalDeviceDatabase entry matching the PCI id of the device and
pointing at that service entry.
While at this, also drop CriticalDeviceDatabase entries for older and
no longer relevant PCI ids of the virtio-blk device.
Tested on
Win XP SP3 x32
Win XP SP2 x64
Win 2003R2 SP2 x32
Win 2003R2 SP2 x63
Win Vista SP2 x32
Win Vista SP2 x64
Win 2008 SP2 x32
Win 2008R2 SP1 x64
Win 7 SP1 x32
Win 7 SP1 x64
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
