If these are not defined in the header files, it's a problem on
the platform which we should fix with gnulib. Our replacement
definitions might be wrong here.
Having a separate directory means:
(1) It's easy to clean up orphaned temporary files, the appliance,
etc.
(2) You can put an SELinux label on this directory so that qemu can
write to it when you're using sVirt and SELinux is enforcing:
chcon --reference=/tmp tmp
This is a fix for multiprogramming: If two instances of libguestfs
share the same appliance disk, then libvirt would unlabel the disk
when one of the instances closes the handle, resulting in the other
qemu being unable to continue accessing the appliance.
Adding the flag makes libvirt understand that the disk is shared so it
doesn't do this, and it apparently handles locking correctly too if we
were using sanlock.
Since 'QEMU' is set (overwritten) by the autoconf-generated Makefile,
this test would always test installed qemu, not upstream qemu,
making it pretty useless. Use another name for this variable.
If you go back in time in git (eg. git reset, git bisect) then you can
end up in a situation where a file that was generated by a later
version is left around unused in the earlier version.
This isn't a problem for most things, but gobject documentation
generation picks up any file in a directory, even unreferenced ones,
and breaks. So the correct thing to do is to remove these files.
I: Program returns random data in a function
E: libguestfs no-return-in-nonvoid-function guestmount.c:75
The function fuse_opt_add_opt_escaped has only one caller and a return
code is not checked.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
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.
This command was not tested at all. As a result we didn't notice that
it was broken for a long time (RHBZ#853159).
This adds a test that drives the command through a pty. It uses the
perl 'Expect' module, although this is not required.
https://bugzilla.redhat.com/show_bug.cgi?id=853159
git bisect pointed to the following commit:
commit ec8e3b6cad
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.
The libvirt backend currently doesn't support direct mode. We should
make that work in future. As a workaround, force the attach-method to
be 'appliance' in this case.
We set the error handler to NULL in order to mask "normal" error
messages that we expect to see because of the unusual way that
virt-rescue runs the appliance. However if the user selected -v /
enabled debugging, then it is reasonable to expect they want to see
every message, so do not mask anything.
guestfs_disk_image makes a symbolic link to the real filename in order
to sanitize the filename. However this fails if the filename is a
relative path. Call realpath(3) to make the filename canonical.
This fixes commit 20902e7ce0.
udevadm is included in all reasonable recent distributions.
This avoids 'command not found' errors in verbose mode.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
