Look for use of external_functions and fish_functions and replace with
use of external_functions_sorted and fish_functions_sorted where
possible. This ensures that the output of the generator is sorted as
far as possible.
I also checked for uses of internal_functions and documented_functions
but those are not used. The *_sorted versions are always used
instead.
This is just a whitespace change.
This was done by running the following command and then fixing a
couple of places where it got it wrong:
perl -pi.bak -e 'unless (m/#define/) { s/([a-zA-Z0-9])\(/$1 (/g }' \
generator/gobject.ml
Switch the type of the "guid" parameter from "String" to "GUID"; this
adds the validation of the GUID as such, rejecting straight away invalid
GUIDs which otherwise could be handled badly by low-level tools (such as
sgdisk).
Add a couple of easy tests (taken from RHBZ#1008417) to
part_set_gpt_type about this.
The path at the protocol level is:
pool/disk
(with no leading '/' character). This is now what you have to pass to
guestfs_add_drive_opts.
Also Ceph can be called with no explicit servers (it uses the contents
of /etc/ceph/ceph.conf instead). So allow zero servers to be used.
Allow settings (an arbitrary list of strings) to be passed to the
current backend. This will allow us to tweak how the backend works,
eg. by forcing TCG.
The .new method was unintentionally broken in
commit 9466060201.
This fixes the .new method and allows it to be called with multiple
parameters, so you can use:
Guestfs::Guestfs.new
Guestfs::Guestfs.new()
Guestfs::Guestfs.new(:close_on_exit => false)
etc.
For backwards compatibility, Guestfs::create may still be used.
This commit also adds regression tests:
- Use .new method in regular tests. (Because this was not done
before, we didn't catch the breakage.)
- Test that ::create still works.
- Test that args can be passed to .new method.
The current add_cdrom way basically appends a new raw "-cdrom /path"
parameter to the qemu invocation (even when using libvirt as backend),
hence such images are seen as "CD-ROM drives" inside the appliance.
However, there is no need for such particular behaviour, as they need to
be handled as normal (read-only) drives.
Adding CD-ROM disk images as drives also changes the device names used
for them inside the appliance from /dev/srN to the usual e.g. /dev/sdX.
These changes fix different issues:
- it is possible to start guestfish without adding disks with -a, then
just add-cdrom and run
- list-devices does not cause guestfsd to crash when sorting the list
of devices (exposed by the test case in RHBZ#563450)
- the result of list-devices now reflects the order images were added
(RHBZ#563450)
add_cdrom is still deprecated, but now in favour of add_drive_ro
(instead of add_drive), with its documentation reflecting that.
Add two small regression tests for the fixes described above.
- when a command needs no parameters, tell that explicitly instead of
"command should have 0 parameters"
- use gettext's plural form when printing the number of required
arguments
- improve the error message for a variable number of parameters limited
only in the maximum number of them, using also a plural form
This adds a new internal API: internal_exit
Only when valgrinding the daemon, have the library call internal_exit
along the close path, and close the sockets first. This ensures we
will see normal valgrind messages (we were only seeing valgrind aborts
before).
Note this is not used in production builds.
When the user has enabled the network (not the default) we upload
/etc/resolv.conf from the host to the appliance /etc/resolv.conf
so that programs in the appliance can contact nameservers.
Commit 9521422ce6 previously changed the
behaviour to copy /etc/resolv.conf into the sysroot when running
commands.
This call never did anything. Don't use it. Also I have submitted a
patch upstream to remove the corresponding option from blockdev.
See RHBZ#1002825 for an explanation of why this call was always
useless.
Thanks: Masayoshi Mizuma
This commit adds an optional 'cachemode' parameter to the 'add_drive'
API to control caching. This corresponds approximately to the
'-drive ...,cache=' parameter in qemu, but the choices are much more
restrictive, just 'writeback' or 'unsafe', for reasons outlined below.
The caching modes supported by recent QEMU are:
writeback:
- Reports data writes completed when data is present in the host
page cache.
Only safe provided guest correctly issues flush operations.
writethrough:
- Reports data writes completed only when each write has been
flushed to disk. Performance is reported as not good.
none:
- Uses O_DIRECT (avoids all interaction with host cache), but does
not ensure every write is flushed to disk.
Only safe provided guest correctly issues flush operations.
directsync:
- Uses O_DIRECT (avoids all interaction with host cache), and
ensures every write has been flushed to disk.
unsafe:
- No special handling.
Since the libguestfs appliance kernel always issues flush operations
(eg. for filesystem journalling and for sync) the following modes can
be ignored: 'directsync', 'writethrough'.
That leaves 'writeback', 'none' and 'unsafe'. However 'none' is both
a constant source of pain (RHBZ#994517), is inefficient because it
doesn't use the host cache, and does not give us any safety guarantees
over and above 'writeback'. Therefore we should ignore 'none'.
This leaves 'writeback' (safe) and 'unsafe' (fast, useful for scratch
disks), which is what we implement in this patch.
Note that the previous behaviour was to use 'none' if possible, else
to use 'writeback'. The new behaviour is to use 'writeback' only
which is (in safety terms) equivalent to 'none', and also faster and
less painful (RHBZ#994517).
This patch also allows you to specify a cache mode for network drives
which also previously defaulted to 'writeback'.
There is a considerable performance benefit to using unsafe (for
scratch disks only, of course). The C API tests only use scratch
disks (since they are just tests, the final state of the disk doesn't
matter), and this decreases total run time from 202 seconds to 163
seconds, about 25% faster.
Previously device name translation worked on the string in-place.
This worked fine because the device strings always come from XDR where
they are dynamically allocated. However it wouldn't work if the
translated name had to be longer than the original, specifically for
/dev/sd -> /dev/ubd (for User Mode Linux).
Therefore this commit changes the generator so that
device_name_translation and parse_btrfsvol (which depends on it)
allocate the new device name instead of overwriting it.
These macros are pretty horrible to use, with unexpected side-effects.
Move them exclusively into the generated code and rewrite the one
place in the general C code which used them.
There's no functional change in this code.
This adds simple support for reading the journal files from guests
that use the systemd journal.
The new APIs are:
journal-open
journal-close
journal-next
journal-skip
journal-get
journal-get-data-threshold
journal-set-data-threshold
internal-journal-get
More complex journal support (eg. for seeking within the journal,
support for cursors) could be added later.
The FileIn/FileOut parameters are not passed through to the daemon.
Previously we generated incorrect RPC code (an empty 'struct
guestfs_<fn>_args') because we didn't account for these FileIn/FileOut
parameters correctly.
