| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The read_all function is used as a callback for
guestfs___cmd_set_stdout_callback (cmd, read_all, [str],
CMD_STDOUT_FLAG_WHOLE_BUFFER);
As noted in the documentation for CMD_STDOUT_FLAG_WHOLE_BUFFER, the
buffer returned is not \0-terminated, and so using memdup will create
an unterminated string, and therefore potentially a memory overrun
when reading or searching the string.
Use strndup instead so the final string is \0-terminated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to get the host's loops_per_jiffy value and pass this on the
command line to the guest. In theory this should avoid the appliance
having to recalculate this value in a VM with TCG (which is generally
error-prone). This should avoid timing issues.
We only do this when we are certain that the guest will be TCG.
Currently we only have enough information to do this from the libvirt
attach-method. So mostly this will only affect people using Fedora in
a VM.
The host loops_per_jiffy value is not exported by the kernel. It is
only printed by the kernel early during boot, so if boot messages have
"scrolled off" the kernel ring buffer, it won't be available. Some
operating systems save early kernel messages in /var/log/dmesg but (a)
Fedora 18+ seem to have abandoned this file and (b) on Ubuntu this
file is unreadable for spurious "security" reasons.
I have submitted a patch to make lpj available through /proc/cpuinfo.
|
| |
|
|
| |
Move this into a common file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the following memory leak found by valgrind:
==13629== 498 (112 direct, 386 indirect) bytes in 1 blocks are definitely lost in loss record 99 of 110
==13629== at 0x4A06B2F: calloc (vg_replace_malloc.c:593)
==13629== by 0x4CA564E: guestfs_safe_calloc (alloc.c:71)
==13629== by 0x4CA9B02: guestfs___new_command (command.c:143)
==13629== by 0x4CA66E9: guestfs___build_appliance (appliance.c:690)
==13629== by 0x4CBD1B9: launch_libvirt (launch-libvirt.c:188)
==13629== by 0x402E7E: main (virt-filesystems.c:349)
Also adjust the command code in several places to make it simpler. We
can almost always call guestfs___cmd_close right after
guestfs___cmd_run, avoiding any need to close the handle along error
paths.
Tested by running the test suite under valgrind.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New API: list-disk-labels
Allow the user to pass an optional disk label when adding a drive.
This is passed through to qemu / libvirt using the disk serial field,
and from there to the appliance which exposes it through udev,
creating a special alias of the device /dev/disk/guestfs/<label>.
Partitions are named /dev/disk/guestfs/<label><partnum>.
virtio-blk and virtio-scsi limit the serial field to 20 bytes. We
further limit the name to maximum 20 ASCII characters in [a-zA-Z].
list-devices and list-partitions are not changed: these calls still
return raw block device names. However a new call, list-disk-labels,
returns a hash table allowing callers to map between disk labels, and
block device and partition names.
This commit also includes a test.
|
| |
|
|
| |
Using an array simplifies the implementation of hotplugging.
|
| |
|
|
|
|
|
| |
Since this is the most common error seen by people who have
installation problems, buggy qemu, etc, and since no one reads the
FAQ, describe in this error message what resources are available to
debug launch problems.
|
| |
|
|
|
|
|
| |
<file>: error: jump skips variable initialization [-Werror=jump-misses-init]
This has only just appeared, possibly related to previous gnulib
update. In any case, this is just code motion / cleanup.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Linux PATH_MAX is 4096, but on some platforms it can be much larger
or even not defined (ie. unlimited). Therefore using a PATH_MAX-sized
stack buffer is not a great idea for portable programs.
This change removes use of PATH_MAX-sized stack-allocated buffers.
This change only applies to the library and standalone programs.
Inside the daemon, memory allocation is much more complicated so I
have not changed those (yet).
Found by 'make syntax-check'.
|
| |
|
|
|
|
|
|
| |
This hint tells the backend whether anyone cares about errors when the
appliance is shut down.
Currently this only has any effect on the libvirt backend, where it
controls whether or not we use the VIR_DOMAIN_DESTROY_GRACEFUL flag.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(RHBZ#853159).
https://bugzilla.redhat.com/show_bug.cgi?id=853159
git bisect pointed to the following commit:
commit ec8e3b6cad170d08ac18b580792dfb137eb171dc
Author: Richard W.M. Jones <rjones@redhat.com>
Date: Fri Jul 20 14:24:10 2012 +0100
launch: Abstract attach method operations.
g->attach_ops points to a structure which contains the
operations supported by each attach method backend
(ie. appliance, unix, etc.).
Since that commit was essentially just code motion, it wasn't clear
why virt-rescue should be affected by it.
In fact the reason is as follows:
(1) In direct mode, we don't need g->fd[] (which would normally be
connected to the stdin/stdout of qemu). So we opened them on
/dev/null so they had some value.
(2) accept_from_daemon / read_log_message_or_eof reads from g->fd[1].
Since this is connected to /dev/null, it always reads EOF.
(3) This would cause child_cleanup to be called. This is completely
unintentional: we don't want to cleanup the child at this point, even
in direct mode.
(4) Prior to the commit above, child_cleanup first waited for the
process to exit (ie. waitpid). This happened to work, since we are
effectively waiting for the user to exit virt-rescue.
(5) After the commit above, the order of operations was changed so
that we first killed qemu before waiting for it. This broke
virt-rescue.
The fix is to change direct mode so that it leaves g->fd[]'s as -1.
The rest of the protocol code can deal with this situation -- it
ignores the log fd instead of trying to read from it.
|
| |
|
|
| |
This reverts commit fe2253088ff51b51e2586f27a9408a38655170e3.
|
| |
|
|
|
|
|
| |
NB: The patch to implement this feature in qemu is not upstream, and
may never make it upstream. However this is so useful for
virt-sparsify that I decided to add this to libguestfs while we see
what qemu decides to do.
|
| |
|
|
| |
Signed-off-by: Masami HIRATA <msmhrt@gmail.com>
|
| |
|
|
| |
attach-method.
|
| |
|
|
| |
It should work with any attach-method.
|
| |
|
|
| |
This is just code motion.
|
| |
|
|
|
|
|
|
|
| |
Since we will be calling guestfs___build_appliance from the libvirt
code in future, there's no point having two places where we have to
acquire the lock. Push the lock down into this function instead.
Because "glthread/lock.h" includes <errno.h> we have to add this
header to the file too.
|
| |
|
|
|
|
| |
g->attach_ops points to a structure which contains the
operations supported by each attach method backend
(ie. appliance, unix, etc.).
|
| |
|
|
|
| |
Although we still use the handle as convenient temporary
storage.
|
| |
|
|
|
|
| |
Move and rewrite guestfs_config so it accumulates a list of qemu
parameters in the handle. These are added to the appliance at launch
time (with attach method == unix:... you'll now get an error).
|
| | |
|
| | |
|
|
|
launch-appliance.c contains the code associated with the 'appliance'
attach-method. Mostly. In fact there are a few APIs which don't fit
so nicely:
- config: deprecated API which fiddles with the qemu command
line directly
- max-disks: depends on the qemu implementation (virtio-scsi
or not)
- debug-drives: used for testing only
launch-unix.c contains the code associated with 'unix:<path>'.
launch.c is the common code for launching, along with a few other APIs
such as guestfs_add_drive_opts.
This commit also reduces the number of headers to just those
which are required.
|
