| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Thanks to Erez Shinan.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new form of progress event, where we don't know how
much of the operation has taken place, but we nevertheless want to
send back some indication of activity. Some progress bar indicators
directly support this, eg. GtkProgressBar where it is known as "pulse
mode".
A pulse mode progress message is a special backwards-compatible form
of the ordinary progress message. No change is required in callers,
unless they want to add support for pulse mode.
The daemon sends:
- zero or more progress messages with position = 0, total = 1
- a single final progress message with position = total = 1
Note that the final progress message may not be sent if the call fails
and returns an error. This is consistent with the behaviour of
ordinary progress messages.
The daemon allows two types of implementation. Either you can just
call notify_progress (0, 1); ...; notify_progress (1, 1) as usual.
Or you can call the functions pulse_mode_start, pulse_mode_end and/or
pulse_mode_cancel (see documentation in daemon/daemon.h). For this
second form of call, the guarantee is very weak: it *just* says the
daemon is still capable of doing something, and it doesn't imply that
if there is a subprocess that it is doing anything. However this does
make it very easy to add pulse mode progress messages to all sorts of
existing calls that depend on long-running external commands.
To do: add a third variant that monitors a subprocess and only sends
back progress messages if it's doing something, where "doing
something" might indicate it's using CPU time or it's printing output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit generates approximate progress messages during the
guestfs_launch call. Currently this code generates:
0 / 12: launch clock starts
3 / 12: appliance created
6 / 12: detected that guest kernel started
9 / 12: detected that /init script is running
12 / 12: launch completed successfully
(Note this is not an ABI and may be changed or removed in a future
version).
Progress messages are only generated at all if 5 seconds have elapsed
since the launch, and they are only generated for the ordinary
appliance (not if using attach-method to attach to an existing virtio
serial port).
|
| |
|
|
| |
This updates commit 4e0cf4dbf8a8a96288f70114fdc3939da0aa7ad1.
|
| |
|
|
|
|
|
|
|
|
|
| |
(Thanks Chris Lalancette).
See:
https://bugzilla.redhat.com/show_bug.cgi?id=664558#c6
Notes:
Labels: bugfix, RHBZ#664558
Depends: 6a64114929a0b098f5a1e31e17e7802127925007
|
| |
|
|
| |
Notes:
Labels: feature
|
| |
|
|
|
|
|
|
|
|
| |
This returns a product variant for inspected operating systems. In
practice this is a useful way to distinguish between consumer and
enterprise/server versions of Windows that otherwise have the same
version number.
Notes:
Labels: feature
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case where both ends cancel at the same time (eg. both ends
realize there are errors before or during the transfer), previously we
skipped sending back an error from the daemon, on the spurious basis
that the library would not need it (the library is cancelling because
of its own error).
However this is wrong: we should always send back an error message
from the daemon in order to preserve synchronization of the protocol.
A simple test case is:
$ guestfish -N fs -m /dev/sda1 upload nosuchfile /
libguestfs: error: open: nosuchfile: No such file or directory
libguestfs: error: unexpected procedure number (66/282)
(Notice two things: there are errors at both ends, and the
loss of synchronization).
After applying this commit, the loss of synchronization does not occur
and we just see the library error:
$ guestfish -N fs -m /dev/sda1 upload nosuchfile /
libguestfs: error: open: nosuchfile: No such file or directory
The choice of displaying the library or the daemon error is fairly
arbitrary in this case -- it would be valid to display either or even
to combine them into one error. Displaying the library error only
makes the code considerably simpler.
This commit also (re-)enables a test for this case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a previous, incorrect attempt to fix RHBZ#576879 we tried to
prevent the daemon from sending an error reply if the daemon had
cancelled the transfer. This is wrong: the daemon should send an
error reply in these cases.
A simple test case is this:
guestfish -N fs -m /dev/sda1 upload big-file /
(This fails because the target "/" is a directory, not a file.)
Prior to this commit, libguestfs would hang instead of printing an
error. With this commit, libguestfs prints an error.
What is happening is:
(1) Library is uploading
a file (2) In the middle of the long
upload, daemon detects an error.
Daemon cancels.
(3) Library detects cancel,
sends cancel chunk, then waits
for the error reply from the
daemon. (4) Daemon is supposed to send
an error reply message.
Because step (4) wasn't happening, uploads that failed like this would
hang in the library (waiting for the error message, while the daemon
was waiting for the next request).
This also adds a regression test.
This temporarily breaks the "both ends cancel" case (RHBZ#576879c5).
Therefore the test for that is disabled, and this is fixed in the next
patch in the series.
This partially reverts commit dc706a639eec16084c0618baf7bfde00c6565f63.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The methods $h->set_progress_callback and $h->clear_progress_callback
have been removed, and replaced with a complete mechanism for setting
and deleting general-purpose events.
This also updates virt-resize to use the new API.
|
| |
|
|
|
|
| |
The functions set_progress_callback and clear_progress_callback have
been removed, and replaced with a complete mechanism for setting and
deleting general-purpose events.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This API allows more than one callback to be registered for each
event, makes it possible to call the API from other languages, and
allows [nearly all] log, debug and trace messages to be rerouted from
stderr.
An older version of this API was discussed on the mailing list here:
https://www.redhat.com/archives/libguestfs/2010-December/msg00081.html
https://www.redhat.com/archives/libguestfs/2011-January/msg00012.html
This also updates guestfish to use the new API for its progress bars.
|
| |
|
|
|
|
|
|
| |
the private data area.
This commit adds new APIs for walking over the keys and pointers in
the private data area associated with each handle (note this is only
applicable to the C API).
|
| |
|
|
|
|
|
|
| |
There was a lot of repeated code to map return types (eg. RErr)
to error cases (eg. -1 or NULL).
This commit introduces an error code type and two functions to
map return types to error codes and error codes to strings.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we expanded the code for 'trace_return' unconditionally for
all non-daemon functions. However this code was not prepared to
handle all error conditions, and in fact would segfault if it tried to
print RStringList or RHashtable where r == NULL.
We need to make the code conditional on the return value, calling
either 'trace_return' or 'trace_return_error' as appropriate.
Note the difficult case for RConstOptString which returns NULL in
non-error cases.
|
| |
|
|
|
|
|
|
|
| |
Creating a HashMap directly from JNI is possible but very tedious
(see: http://java.sun.com/docs/books/jni/html/fldmeth.html#26254)
Instead we use the existing code to return hashes from JNI as plain
String[], then add some code in the Java wrapper to convert these to
HashMap<String,String>.
|
| |
|
|
|
|
|
|
| |
There's no point returning the specific HashMap type here.
Return the generic interface type instead.
Note that no users are actually calling these functions yet,
since at present they always fail.
|
| |
|
|
|
| |
In functions that don't have javadoc, the function prototype wasn't
being indented correctly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This optional flag controls whether this API call will try to connect
to a running virtual machine 'guestfsd' process.
If the flag is given and the virtual machine is running, then the
libvirt XML is parsed looking for a suitable <channel> element, and
'guestfs_set_attach_method' is called with the corresponding
virtio-serial socket path.
|
| |
|
|
|
|
|
|
|
|
| |
These allow you to get and set the attach method. The format
is one of:
* appliance
* unix:<path>
It's stored broken out into an enum and a string in the handle.
|
| |
|
|
|
|
|
|
|
| |
Instead of explicitly calling umount-all; sync, we add a daemon
function called internal-autosync which does the same.
Apart from slightly simplifying the process of closing the handle, the
main advantage is we can modify the daemon for the standalone case so
that internal-autosync does not do the umount-all operation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also separate the call and return lines so that everything can be
easily 'grepped' from debug output. The trace output now looks like
this:
$ guestfish -x -N fs exit
libguestfs: trace: is_config
libguestfs: trace: is_config = 1
libguestfs: trace: add_drive "test1.img"
libguestfs: trace: add_drive = 0
libguestfs: trace: is_config
libguestfs: trace: is_config = 1
libguestfs: trace: launch
libguestfs: trace: launch = 0
libguestfs: trace: part_disk "/dev/sda" "mbr"
libguestfs: trace: part_disk = 0
&c.
|
| |
|
|
|
| |
This allows the -O parameter to be added to the mkfs command line.
This is used to select filesystem features.
|
| | |
|
| | |
|
| |
|
|
|
| |
For examples of the virt-inspector output, see the additional
inspector/example-*.xml files in this commit.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix guestfish (and other C tools) so that they ignore errors
when /etc/fstab contains bogus entries.
Update the documentation for inspect-get-mountpoints to emphasize
that callers must be aware of this when mounting the returned
values.
Add a regression test.
Update the example code ("inspect_vm") to reflect the way this
API ought to be called.
For more detail see:
https://bugzilla.redhat.com/show_bug.cgi?id=668574
|
| | |
|
| |
|
|
|
|
| |
Add a new section called "EXTENDING LIBGUESTFS" to the
guestfs manual page which contains all the information
previously in "HACKING".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These APIs are essentially required to work around a problem
with ntfs-3g. This filesystem (or FUSE?) does not list all
extended attributes of a file when you call listxattr(2). However
if you know the name of an extended attribute, you can retrieve
it directly using getxattr(2).
The current APIs (getxattrs etc) are simple to use, but they
don't work if we can't list out the extended attributes (ie.
by calling listxattr(2)).
Example using the new APIs on an ntfs-3g filesystem:
><fs> lgetxattr "/Documents and Settings" system.ntfs_attrib | hexdump -C
00000000 16 24 00 00 |.$..|
00000004
><fs> lgetxattr "/Documents and Settings" system.ntfs_reparse_data | hexdump -C
00000000 03 00 00 a0 34 00 00 00 00 00 18 00 1a 00 10 00 |....4...........|
00000010 5c 00 3f 00 3f 00 5c 00 43 00 3a 00 5c 00 55 00 |\.?.?.\.C.:.\.U.|
00000020 73 00 65 00 72 00 73 00 00 00 43 00 3a 00 5c 00 |s.e.r.s...C.:.\.|
00000030 55 00 73 00 65 00 72 00 73 00 00 00 |U.s.e.r.s...|
0000003c
><fs> getxattr "/Documents and Settings" system.ntfs_reparse_data | hexdump -C
libguestfs: error: getxattr: getxattr: No such file or directory
><fs> getxattr "/Documents and Settings" system.ntfs_attrib | hexdump -C
libguestfs: error: getxattr: getxattr: No such file or directory
><fs> lgetxattr "/Documents and Settings" system.ntfs_attrib | hexdump -C
00000000 16 24 00 00 |.$..|
00000004
><fs> getxattr "/Users" system.ntfs_attrib | hexdump -C
00000000 11 00 00 00 |....|
00000004
|
| | |
|
| |
|
|
|
|
| |
This is an extensible version of 'mkfs' which supports optional
arguments. There is now no need for 'mkfs_b' since you should
use 'mkfs_opts' with the optional 'blocksize' argument instead.
|
| |
|
|
|
|
|
|
| |
Previously we only supported optional arguments for library
functions (commit 14490c3e1aac61c6ac90f28828896683f64f0dc9).
This extends that work so that optional arguments can also be
passed through to the daemon.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
For actions that have FileIn arguments, count the size of all
the input files and send that in the progress_hint field of the
request header.
|
| |
|
|
|
|
|
|
| |
Two unrelated changes to the protocol to support progress
messages during uploads, and optional arguments.
Note that this makes an incompatible change to the protocol,
and this is reflected in the protocol version field (3 -> 4).
|
| |
|
|
|
|
|
|
|
| |
These tests run much more quickly if you don't have to run
'mkfs' and (particularly) partitioning/LV commands between each
test.
The total time for running 'make -C capitests check' on my laptop
has gone from 413 seconds down to 221 seconds.
|
| |
|
|
|
|
| |
This should allow us to perform filesystem-based write
tests much more quickly, because we don't need to recreate
the filesystem from scratch each time.
|
