| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The second parameter to 'config' may be NULL.
In commit 52fa23d74f6308daf804c2330b0b27e0b4412594 (refactoring of
guestfs_config) the code this got lost, and guestfs_config would
segfault if qemu_value was NULL.
Also this fixes the libvirt method to handle the same case.
I checked libguestfs-1.18 and -1.16 branches, and this problem does
NOT affect them.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
This is a workaround for a bug with virtio-scsi in qemu 1.2:
https://bugzilla.redhat.com/show_bug.cgi?id=847549
|
|
|
|
|
|
| |
function.
This is just code motion / simplification.
|
|
|
|
|
|
| |
This lets us create g->tmpdir lazily earlier if needed.
This commit is just code motion.
|
|
|
|
| |
attach-method.
|
|
|
|
| |
It should work with any attach-method.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Complete the attach-method libvirt backend.
This backend uses libvirt to create a transient KVM domain to run the
appliance.
Note that this still will only work with local libvirt URIs since the
<kernel>, <initrd> and appliance links in the libvirt XML refer to
local files, and virtio serial only works locally (limitation of
libvirt). Remote support will be added later.
|
|
|
|
|
| |
With this commit, you can set the attach method to libvirt,
but calling launch will give an error.
|
|
|
|
|
|
| |
g->attach_ops points to a structure which contains the
operations supported by each attach method backend
(ie. appliance, unix, etc.).
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Note that debug* calls are not part of the stable API and can be
removed or changed at any time.
|
|
|
|
|
|
| |
By using the once_had_no_optargs flag, this change is backwards
compatible for callers (except Haskell, PHP and GObject as discussed
in earlier commit).
|
|
|
|
|
|
| |
This reverts commit 6e5a85bb9b6557bc337625a339728e23f5f2dd94.
It turns out this is a bug in QEMU after all.
|
|
|
|
|
|
|
| |
https://bugs.launchpad.net/qemu/+bug/1021649 is invalid, probably
caused by a Fedora ROM.
This updates commit 52d188e32fb8addb45bf926df07e34ab35898f85.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new API splits orderly close into a two-step process:
if (guestfs_shutdown (g) == -1) {
/* handle the error, eg. qemu error */
}
guestfs_close (g);
Note that the explicit shutdown step is only necessary in the case
where you have made changes to the disk image and want to handle write
errors. Read the documentation for further information.
This change also:
- deprecates guestfs_kill_subprocess
- turns guestfs_kill_subprocess into the same as guestfs_shutdown
- changes guestfish and other tools to call shutdown + close
where necessary (not for read-only tools)
- updates documentation
- updates examples
|
|
|
|
| |
This is just a comment and has no functional effect.
|
|
|
|
|
| |
Note that qemu treats these identically, so this change has
no functional effect.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stdin and stdout of the qemu process are aliased to g->fd:
g->fd[0] = wfd[1];
g->fd[1] = rfd[0];
However if the child exits early, then child_cleanup closes g->fd[0],
g->fd[1], AND the code at the cleanup1 label closes wfd[1], rfd[0],
resulting in a double-close.
Avoid this case by setting wfd[1], rfd[0] to -1. In the cleanup1
label, only close wfd[1], rfd[0] if they are not -1, and add the same
for g->fd[0], g->fd[1].
|
| |
|
|
|
|
| |
This fixes commit ef5c02c6ee72eb8e127115923951777a2c2b8480.
|
| |
|
|
|
|
|
|
|
|
|
| |
Old KVM can't add /dev/null readonly. Treat /dev/null as a special
case.
We also fix a few tests where /dev/null was being used with
format=qcow2. This was always incorrect behaviour, but qemu appears
to tolerate it.
|
|
|
|
| |
This fixes commit 295d6af48d1d8c5238d1536b0c6a2ece42b0b445.
|
|
|
|
|
| |
In Koji, when you've got 200+ disks, udev times out before all the
udev events have been processed.
|
|
|
|
| |
Returns the maximum number of disks that may be added to a handle.
|
|
|
|
| |
This fixes commit 0c0a7d0d868d153adf0600189f771459e1068b0a.
|
|
|
|
| |
This requires febootstrap >= 3.15.
|
|
|
|
|
| |
This allows us to find out what qemu devices are supported
at runtime.
|
|
|
|
|
|
|
|
|
|
|
| |
QEMU 1.0 was released at the end of 2011.
Remove all the cruft about detecting broken -machine type which
was only required for QEMU 0.15.
This also reverts commit 30ecbf3ec2ada68f7e125a180553e31b069033b7.
Even on ARM you can pass -machine accel=kvm:tcg and qemu does the
right thing, so I'm not sure why we wanted to disable that.
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were used to select the default drive and network interface.
They both default to 'virtio'.
These were added back in the day when virtio was buggy, so that
packagers could revert to using ide/ne2k_pci to work around distro
bugs. However virtio has been stable in qemu for a very long time, so
it seems unlikely that any packager would need to use these, and in
any case it would be better to do this detection at runtime (cf. for
virtio-scsi).
|
|
|
|
| |
No functional change.
|
| |
|
|
|
|
| |
This is just code motion.
|
|
|
|
|
|
|
| |
This flag allows extra QEMU options to be passed on the command line.
This is useful mainly on arm (see the notes in the updated README
file).
|
|
|
|
|
|
|
| |
Presently KVM is only applicable to x86 and x86-64 (although that will
change in future, and there are rumoured to be implementations for
some current non-x86 architectures). In any case having these options
breaks ARM, so disable them for non-x86 architectures at the moment.
|
|
|
|
| |
Cope with unnecessary lack of standardization.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally this state was intended so that in some way you could find
out if the appliance was running a command. However there was never a
thread-safe way to access the state of the handle, so in effect you
could never do anything useful safely with this information.
This commit completely removes the BUSY state.
The only visible change is to the guestfs_is_busy API. Previously you
could never call this safely from another thread. If you called it
from the same thread it would always return false (since the current
thread can't be running a libguestfs command at that point by
definition). Now it always returns false.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the bogus check_path function and move the functionality into
the two places where it was being used.
qemu -cdrom ,
works fine, I tested it.
Colon cannot be used in a block device filename anywhere, since the
qemu block driver interprets it as a prefix. There is no known way to
work around this problem. I checked this is true with kwolf.
Comma is fine in -drive options, provided it is escaped by doubling it.
|
|
|
|
| |
This reverts commit be47b66c3033105a2b880dbc10bfc2b163b7eafe.
|
|
|
|
|
| |
This caused the Python bindings (and probably others) to
segfault because guestfs_last_error(g) would return NULL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The presumption is that all file descriptors should be created with
the close-on-exec flag set. The only exception are file descriptors
that we want passed through to exec'd subprocesses (mainly pipes and
stdin/stdout/stderr).
For open calls, we pass O_CLOEXEC as an extra flag, eg:
fd = open ("foo", O_RDONLY|O_CLOEXEC);
This is a Linux-ism, but using a macro we can easily make it portable.
For sockets, similarly:
sock = socket (..., SOCK_STREAM|SOCK_CLOEXEC, ...);
For accepted sockets, we use the Linux accept4 system call which
allows flags to be supplied, but we use the Gnulib 'accept4' module to
make this portable.
For dup, dup2, we use the Linux dup3 system call, and the Gnulib
modules 'dup3' and 'cloexec'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
process.
If the parent process uses a pipe (or any fd, but pipes are a
particular problem), then the recovery process would hold open the
file descriptor(s) of the pipe, meaning that it could not be fully
closed in the parent. Because the recovery process doesn't use
exec(2), this wasn't avoidable even using FD_CLOEXEC.
Avoid this by closing all file descriptors when starting the recovery
process.
After discussion with Dan Berrange, he points out that it's also a
good idea to set signal handlers to the default after forking, so that
any signal handlers set up in the parent don't affect the child.
|