| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As explained in the comment:
/* QEMU's console emulates a 16550A serial port. The real 16550A
* device has a small FIFO buffer (16 bytes) which means here we see
* lots of small reads of 1-16 bytes in length, usually single
* bytes. Sleeping here for a very brief period groups reads
* together (so we usually get a few lines of output at once) and
* improves overall throughput, as well as making the event
* interface a bit more sane for callers. With a virtio-serial
* based console (not yet implemented) we may be able to remove
* this. XXX
*/
|
| |
|
|
| |
This is just code motion.
|
| |
|
|
| |
This is just code motion.
|
| |
|
|
|
| |
This should be obvious, and now it is documented to avoid any
confusion.
|
| |
|
|
| |
This updates commit 4e0cf4dbf8a8a96288f70114fdc3939da0aa7ad1.
|
| | |
|
| | |
|
| |
|
|
| |
Fix commit b8e1dee73a1deef1bfd5937e2abfbe9afef7b1ef.
|
| | |
|
| |
|
|
|
|
| |
This is like the mythical 'virt-ifconfig'. There is not enough
certainty around the right way to be doing this for us to make
a full virt tool for this. Therefore the code is just an example.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
These applications are located along a different Registry path. See
http://support.microsoft.com/kb/896459 for all the details.
Thanks Jinxin Zheng for finding the bug and the solution.
|
| |
|
|
|
| |
This allows the default for --ro or --rw to be controlled for the
three tools guestfish, guestmount and virt-rescue.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Lift the if HAVE_PO4A ... endif completely out of the po-docs
subdirectory, and just exclude the whole subdirectory if the po4a
program is not available.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation for the getxattr and listxattr calls is not very
clear and as a result we were always returning something different
from that which the Linux kernel would usually return.
This fixes these calls, at least far enough that both the 'getfattr'
and 'getfacl' programs now work fine on FUSE-mounted filesystems.
Note that SELinux attrs are *not* passed through. This appears to be
a known bug between SELinux and FUSE. For more information see:
http://www.spinics.net/lists/selinux/msg09460.html
Notes:
Labels: bugfix, RHBZ#691389
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This lets you turn on ACLs and xattrs by doing:
-m /dev/sda1:/:acl,user_xattr
The extra parameter is passed through to mount_options:
libguestfs: trace: mount_options "acl,user_xattr" "/dev/sda1" "/"
Notes:
Labels: feature
|
| |
|
|
| |
See: https://www.redhat.com/archives/libguestfs/2011-March/msg00124.html
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
(Thanks Chris Lalancette).
See:
https://bugzilla.redhat.com/show_bug.cgi?id=664558#c6
Notes:
Labels: bugfix, RHBZ#664558
Depends: 6a64114929a0b098f5a1e31e17e7802127925007
|
| |
|
|
|
| |
Notes:
Labels: cleanup, forcestable
Depends: 227bea6c7ef89b707fe2c01c4d0d0fb9081e8c04
|
| |
|
|
| |
Notes:
Labels: bugfix, RHBZ#690819
|
| |
|
|
|
|
|
|
| |
No functional change; this simply makes the purpose of the
socket clearer.
Notes:
Labels: cleanup
|
| |
|
|
| |
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
|
| |
|
|
|
| |
Notes:
Labels: cleanup
Depends: c8faa5d0b0a17689d27bd33bc787ba0fe9a3f076
|
| |
|
|
| |
Notes:
Labels: bugfix
|
| |
|
|
|
| |
Notes:
Labels: bugfix, RHBZ#674130
Depends: 5776c145d411e5ae00072ecf422055f3d0bd29e2
|
| |
|
|
|
|
|
|
|
| |
Add special is_file_nocase and is_dir_nocase functions and
remove the duplicate checks for files and directories with
different cases.
Notes:
Labels: codemotion
|
| |
|
|
|
|
|
|
|
|
| |
The particular issue is that ntfs-3g (or FUSE?) no longer appears
to update /etc/mtab, which meant that umount-all was not unmounting
these partitions. But parsing /proc/mounts is simpler and more
robust in any case.
Notes:
Labels: bugfix
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a (potential) fix for the long standing protocol bug
which causes loss of synchronization when a FileIn action
fails very early on the daemon side. The canonical example
would be the 'upload' action failing immediately if no filesystem
is mounted.
What's supposed to happen is this:
(1) library sends
request message (2) daemon processes request
first chunk of data and sees that it will fail,
sends cancellation
(3) discards chunks of data
(4) library sees daemon
cancellation and stops
sending chunks
It was going wrong in step (1), in guestfs___send_to_daemon.
In some (timing related) circumstances, send_to_daemon could
receive the cancellation before sending the first chunk, at
which point it would exit, *discarding the first chunk*.
This causes the daemon to fail in step (3) since it reads the
next request as if it was a chunk, thus losing synchronization.
(The protocol specifies that you always have to send at least
one chunk if there is a FileIn or FileOut parameter).
The patch changes guestfs___send_to_daemon so that if it detects
cancellation, it sends the remaining data in its output buffer
instead of discarding it. (This also fixes another edge case
to do with sending partial data although I don't think we
ever saw that in practice).
|
| |
|
|
|
|
|
|
| |
This adds 'guestfsd: ...' prefix before each message, and
also puts a message at the top of the main loop just after
a new message has been received.
The intent is to make it simpler to follow the protocol.
|
