The existing brXXX APIs in src/util/bridge.h are renamed to
follow one of three different conventions
- virNetDevXXX - operations for any type of interface
- virNetDevBridgeXXX - operations for bridge interfaces
- virNetDevTapXXX - operations for tap interfaces
* src/util/bridge.h, src/util/bridge.c: Rename all APIs
* src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/uml/uml_conf.c,
src/uml/uml_driver.c: Update for API renaming
Currently every caller of the brXXX APIs has to store the returned
errno value and then raise an error message. This results in
inconsistent error messages across drivers, additional burden on
the callers and makes the error reporting inaccurate since it is
hard to distinguish different scenarios from 1 errno value.
* src/util/bridge.c: Raise errors instead of returning errnos
* src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/qemu/qemu_command.c, src/uml/uml_conf.c,
src/uml/uml_driver.c: Remove error reporting code
The bridge management APIs in src/util/bridge.c require a brControl
object to be passed around. This holds the file descriptor for the
control socket. This extra object complicates use of the API for
only a minor efficiency gain, which is in turn entirely offset by
the need to fork/exec the brctl command for STP configuration.
This patch removes the 'brControl' object entirely, instead opening
the control socket & closing it again within the scope of each method.
The parameter names for the APIs are also made to consistently use
'brname' for bridge device name, and 'ifname' for an interface
device name. Finally annotations are added for non-NULL parameters
and return check validation
* src/util/bridge.c, src/util/bridge.h: Remove brControl object
and update API parameter names & annotations.
* src/lxc/lxc_driver.c, src/network/bridge_driver.c,
src/uml/uml_conf.h, src/uml/uml_conf.c, src/uml/uml_driver.c,
src/qemu/qemu_command.c, src/qemu/qemu_conf.h,
src/qemu/qemu_driver.c: Remove reference to 'brControl' object
Commit f7bd00c12 pulled in a gnulib module that fails to compile
on mingw. Work around it while waiting for an upstream gnulib fix.
* gnulib/local/lib/pty.in.h (openpty): Provide forward
declarations of opaque structs not present on mingw.
* gnulib/local/lib/openpty.c (openpty): Provide stub for mingw.
Commit f7bd00c12 pulled in a gnulib module that fails to compile
on mingw. While it would be nice to pull in a newer version of
.gnulib that fixes this, it is difficult to backport any .gnulib
update to older releases. So, it makes sense to take advantage
of gnulib-tool's ability to support local diffs, where we can
apply specific diffs in our use of gnulib without waiting for
upstream gnulib to pick up those changes, as well as avoiding
a wholesale .gnulib update. The existence of local diffs will
also make it easier to backport fixes against a tarball (as long
as a tarball and libvirt.git share the same .gnulib commit, then
the tarball can be patched by applying the same local diffs as
a post-release libvirt.git commit, without having to rerun an
entire gnulib-tool bootstrap).
This patch introduces the framework for supporting local diffs,
without actually introducing any.
* bootstrap.conf (local_gl_dir): New variable.
* autogen.sh (bootstrap_hash): Hash any local diffs, to force a
re-bootstrap if just diffs change.
* cfg.mk (_update_required): Likewise.
As the description of removing CDROM media from
http://wiki.libvirt.org/page/QEMUSwitchToLibvirt#eject_DEV
Add flag 'VSH_OFLAG_EMPTY_OK' to the option 'source' of attach-disk
Then avoid outputting <source> in the XML if 'source' was empty,
rather than trusting libvirt domain_conf.c to understand an empty
string.
Signed-off-by: Xu He Jie <xuhj@linux.vnet.ibm.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
MacOS lacks ptsname_r, and gnulib doesn't (yet) provide it.
But we can avoid it altogether, by using gnulib openpty()
instead. Note that we do _not_ want the pt_chown module;
gnulib uses it only to implement a replacement openpty() if
the system lacks both openpty() and granpt(), but all
systems that we currently port to either have at least one of
openpty() and/or grantpt(), or lack ptys altogether. That is,
we aren't porting to any system that requires us to deal with
the hassle of installing a setuid pt_chown helper just to use
gnulib's ability to provide openpty() on obscure platforms.
* .gnulib: Update to latest, for openpty fixes
* bootstrap.conf (gnulib_modules): Add openpty, ttyname_r.
(gnulib_tool_option_extras): Exclude pt_chown module.
* src/util/util.c (virFileOpenTty): Rewrite in terms of openpty
and ttyname_r.
* src/util/util.h (virFileOpenTtyAt): Delete dead prototype.
Every instance of virCapsPtr must have the defaultConsoleTargetType
field set.
* src/security/virt-aa-helper.c: Add defaultConsoleTargetType to
virCapsPtr
The code calling sendfd/recvfd was mistakenly assuming those
calls would never block. They can in fact return EAGAIN and
this is causing us to drop the client connection when blocking
ocurrs while sending/receiving FDs.
Fixing this is a little hairy on the incoming side, since at
the point where we see the EAGAIN, we already thought we had
finished receiving all data for the packet. So we play a little
trick to reset bufferOffset again and go back into polling for
more data.
* src/rpc/virnetsocket.c, src/rpc/virnetsocket.h: Update
virNetSocketSendFD/RecvFD to return 0 on EAGAIN, or 1
on success
* src/rpc/virnetclient.c: Move decoding of header & fds
out of virNetClientCallDispatch and into virNetClientIOHandleInput.
Handling blocking when sending/receiving FDs
* src/rpc/virnetmessage.h: Add a 'donefds' field to track
how many FDs we've sent / received
* src/rpc/virnetserverclient.c: Handling blocking when
sending/receiving FDs
Building on 64-bit FreeBSD 8.2 complained about a cast between
a pointer and a smaller integer. Going through an intermediate
cast shuts up the compiler.
* src/util/threads-pthread.c (virThreadSelfID): Silence a warning.
While building on FreeBSD (and after fixing a ptsname_r link error),
I got this failure:
./.libs/libvirt_util.a(libvirt_util_la-threads.o)(.text+0x240): In function `virThreadCreate':
util/threads-pthread.c:185: undefined reference to `pthread_create'
It turns out that gnulib used only pthread_join for LIB_PTHREAD,
but on FreeBSD, libc provides that (as a stub function); whereas
the more complex pthread_create really does require -pthread,
which gnulib tracked under [LT]LIBMULTITHREAD.
* configure.ac (LIBS): Check LIBMULTITHREAD alongside LIB_PTHREAD.
* src/Makefile.am (THREAD_LIBS): New variable.
(libvirt_util_la_LIBADD, libvirt_lxc_LDADD): Use it.
I got this weird failure:
error: Failed to start domain simple
error: internal error cannot mix caller fds with blocking execution
and tracked it down to a use-after-free - virCommandSetOutputFD
was storing the address of a stack-local variable, which then
went out of scope before the virCommandRun that dereferenced it.
Bug introduced in commit 451cfd05 (0.9.2).
* src/lxc/lxc_driver.c (lxcBuildControllerCmd): Move log fd
registration...
(lxcVmStart): ...to caller.
All constants related to events should have a prefix of
VIR_DOMAIN_EVENT_
* include/libvirt/libvirt.h.in, src/qemu/qemu_domain.c:
Rename VIR_DOMAIN_DISK_CHANGE_MISSING_ON_START to
VIR_DOMAIN_EVENT_DISK_CHANGE_MISSING_ON_START
I ran into the following build failure:
$ mkdir -p build1 build2/a/very/deep/hierarcy
$ cd build2/a/very/deep/hierarcy
$ ../../../../../configure && make
$ cd ../../../../build1
$ ../configure && make
...
../../src/remote/remote_protocol.c:7:55: fatal error: ../../../../../src/remote/remote_protocol.h: No such file or directory
Turns out that we were sometimes generating the remote_protocol.c
file with information from the VPATH build, which is bad, since
any file shipped in the tarball should be idempotent no matter how
deep the VPATH build tree that created it.
* src/rpc/genprotocol.pl: Don't embed VPATH into generated file.
Based on a Coverity report - the return value of waitpid() should
always be checked, to avoid problems with leaking resources.
* src/lxc/lxc_controller.c (lxcControllerRun): Use simpler virPidAbort.
The default console type may vary based on the OS type. ie a Xen
paravirt guests wants a 'xen' console, while a fullvirt guests
wants a 'serial' console.
A plain integer default console type in the capabilities does
not suffice. Instead introduce a callback that is passed the
OS type.
* src/conf/capabilities.h: Use a callback for default console
type
* src/conf/domain_conf.c, src/conf/domain_conf.h: Use callback
for default console type. Add missing LXC/OpenVZ console types.
* src/esx/esx_driver.c, src/libxl/libxl_conf.c,
src/lxc/lxc_conf.c, src/openvz/openvz_conf.c,
src/phyp/phyp_driver.c, src/qemu/qemu_capabilities.c,
src/uml/uml_conf.c, src/vbox/vbox_tmpl.c,
src/vmware/vmware_conf.c, src/xen/xen_hypervisor.c,
src/xenapi/xenapi_driver.c: Set default console type callback
To allow virDomainOpenConsole to access non-primary consoles,
device aliases are required to be set. Until now only the QEMU
driver has done this. Update LXC & UML to set aliases for any
console devices
* src/lxc/lxc_driver.c, src/uml/uml_driver.c: Set aliases
for console devices
When no <target> element was set at all, the default console
target type was not being honoured
* src/conf/domain_conf.c: Set default target type for consoles
with no <target>
Currently the LXC controller only supports setup of a single
text console. This is wired up to the container init's stdio,
as well as /dev/console and /dev/tty1. Extending support for
multiple consoles, means wiring up additional PTYs to /dev/tty2,
/dev/tty3, etc, etc. The LXC controller is passed multiple open
file handles, one for each console requested.
* src/lxc/lxc_container.c, src/lxc/lxc_container.h: Wire up
all the /dev/ttyN links required to symlink to /dev/pts/NN
* src/lxc/lxc_container.h: Open more container side /dev/pts/NN
devices, and adapt event loop to handle I/O from all consoles
* src/lxc/lxc_driver.c: Setup multiple host side PTYs
The current I/O code for LXC uses a hand crafted event loop
to forward I/O between the container & host app, based on
epoll to handle EOF on PTYs. This event loop is not easily
extensible to add more consoles, or monitor other types of
file descriptors.
Remove the custom event loop and replace it with a normal
libvirt event loop. When detecting EOF on a PTY, disable
the event watch on that FD, and fork off a background thread
that does a edge-triggered epoll() on the FD. When the FD
finally shows new incoming data, the thread re-enables the
watch on the FD and exits.
When getting EOF from a read() on the PTY, the existing code
would do waitpid(WNOHANG) to see if the container had exited.
Unfortunately there is a race condition, because even though
the process has closed its stdio handles, it might still
exist.
To deal with this the new event loop uses a SIG_CHILD handler
to perform the waitpid only when the container is known to
have actually exited.
* src/lxc/lxc_controller.c: Rewrite the event loop to use
the standard APIs.
qemuBuildVirtioSerialPortDevStr was mistakenly accessing the
target.name field in the virDomainChrDef object for chardevs
belonging to a console. Those chardevs only have port set,
and if there's > 1 console, the > 1port number results in
trying to access a target.name with address 0x1
* src/qemu/qemu_command.c: Fix target.name handling and
make code more robust wrt error reporting
* src/qemu/qemu_command.c: Conditionally access target.name
While Xen only has a single paravirt console, UML, and
QEMU both support multiple paravirt consoles. The LXC
driver can also be trivially made to support multiple
consoles. This patch extends the XML to allow multiple
<console> elements in the XML. It also makes the UML
and QEMU drivers support this config.
* src/conf/domain_conf.c, src/conf/domain_conf.h: Allow
multiple <console> devices
* src/lxc/lxc_driver.c, src/xen/xen_driver.c,
src/xenxs/xen_sxpr.c, src/xenxs/xen_xm.c: Update for
internal API changes
* src/security/security_selinux.c, src/security/virt-aa-helper.c:
Only label consoles that aren't a copy of the serial device
* src/qemu/qemu_command.c, src/qemu/qemu_driver.c,
src/qemu/qemu_process.c, src/uml/uml_conf.c,
src/uml/uml_driver.c: Support multiple console devices
* tests/qemuxml2xmltest.c, tests/qemuxml2argvtest.c: Extra
tests for multiple virtio consoles. Set QEMU_CAPS_CHARDEV
for all console /channel tests
* tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-auto.args,
tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
tests/qemuxml2argvdata/qemuxml2argv-console-virtio.args: Update
for correct chardev syntax
* tests/qemuxml2argvdata/qemuxml2argv-console-virtio-many.args,
tests/qemuxml2argvdata/qemuxml2argv-console-virtio-many.xml: New
test file
The test case errors should not be translated since they're only
targetted at developers, not users.
* tests/virnetsockettest.c: Remove error reporting with translations
Allow the user to call with nparams too small, per API documentation.
* src/xen/xen_hypervisor.c (xenHypervisorGetSchedulerParameters):
Allow fewer than max.
* src/xen/xend_internal.c (xenDaemonGetSchedulerParameters):
Likewise.
libvirt.c guarantees that nparams is non-zero for scheduler parameters.
* src/test/test_driver.c (testDomainGetSchedulerParamsFlags): Drop
redundant check. Avoid strcpy.
Allow the user to call with nparams too small, per API documentation.
Also, libvirt.c filters out nparams of 0 for scheduler parameters.
* src/lxc/lxc_driver.c (lxcDomainGetMemoryParameters): Allow fewer
than max.
(lxcGetSchedulerParametersFlags): Drop redundant check.
Allow the user to call with nparams too small, per API documentation.
* src/libxl/libxl_driver.c
(libxlDomainGetSchedulerParametersFlags): Allow fewer than max.
Allow the user to call with nparams too small, per API documentation.
* src/esx/esx_driver.c (esxDomainGetMemoryParameters): Drop
redundant check.
(esxDomainGetSchedulerParametersFlags): Allow fewer than max.
Document the parameter names that will be used by
virDomain{Get,Set}SchedulerParameters{,Flags}, rather than
hard-coding those names in each driver, to match what is
done with memory, blkio, and blockstats parameters.
* include/libvirt/libvirt.h.in (VIR_DOMAIN_SCHEDULER_CPU_SHARES)
(VIR_DOMAIN_SCHEDULER_VCPU_PERIOD)
(VIR_DOMAIN_SCHEDULER_VCPU_QUOTA, VIR_DOMAIN_SCHEDULER_WEIGHT)
(VIR_DOMAIN_SCHEDULER_CAP, VIR_DOMAIN_SCHEDULER_RESERVATION)
(VIR_DOMAIN_SCHEDULER_LIMIT, VIR_DOMAIN_SCHEDULER_SHARES): New
field name macros.
* src/qemu/qemu_driver.c (qemuSetSchedulerParametersFlags)
(qemuGetSchedulerParametersFlags): Use new defines.
* src/test/test_driver.c (testDomainGetSchedulerParamsFlags)
(testDomainSetSchedulerParamsFlags): Likewise.
* src/xen/xen_hypervisor.c (xenHypervisorGetSchedulerParameters)
(xenHypervisorSetSchedulerParameters): Likewise.
* src/xen/xend_internal.c (xenDaemonGetSchedulerParameters)
(xenDaemonSetSchedulerParameters): Likewise.
* src/lxc/lxc_driver.c (lxcSetSchedulerParametersFlags)
(lxcGetSchedulerParametersFlags): Likewise.
* src/esx/esx_driver.c (esxDomainGetSchedulerParametersFlags)
(esxDomainSetSchedulerParametersFlags): Likewise.
* src/libxl/libxl_driver.c (libxlDomainGetSchedulerParametersFlags)
(libxlDomainSetSchedulerParametersFlags): Likewise.
The field 'mon' in 'struct tm' gives months 0-11, where as
humans tend to expect months 1-12. Thus the month number
needing adjusting by 1
* src/util/logging.c: Use human friendly month number
commit 27908453 introduces a regression, and it will
cause libvirt crashed when starting network.
The reason is that tapfd may be NULL, but we dereference
it without checking whether it is NULL.
Since all virTypedParameter APIs allow us to return the number
of slots we actually populated, we should allow the user to
call with nparams too small (without overrunning their array)
or too large (ignoring the tail of the array that we can't fill),
rather than requiring that they get things exactly right.
Making this change will make it easier for a future patch to
introduce VIR_TYPED_PARAM_STRING, with filtering in libvirt.c
rather than in every single driver, since users already have
to be prepared for *nparams to be smaller on exit than on entry.
* src/qemu/qemu_driver.c (qemuDomainGetBlkioParameters)
(qemuDomainGetMemoryParameters): Allow variable nparams on entry.
(qemuGetSchedulerParametersFlags): Drop redundant check.
(qemudDomainBlockStats, qemudDomainBlockStatsFlags): Rename...
(qemuDomainBlockStats, qemuDomainBlockStatsFlags): ...to this.
Don't return unavailable stats.
virDomainBlockStatsFlags was missing a check that was present in
virDomainGetMemoryParameters. Additionally, I found that the
existing descriptions were a bit hard to read. A later patch
will fix qemu to return fewer than max parameters if @nparams
was too small on input.
* src/libvirt.c (virDomainGetMemoryParameters)
(virDomainGetBlkioParameters, virDomainGetSchedulerParameters)
(virDomainGetSchedulerParametersFlags):
Tweak documentation wording.
(virDomainBlockStatsFlags): Likewise, and add sanity check.
If an LXC VM fails to start, quite a few cleanup paths will
result in the original error message being overwritten. Some
other cleanup paths also forgot to actually terminate the VM.
* src/lxc/lxc_driver.c: Ensure VM is terminated on startup
failure and preserve original error
The LXC code for mounting container filesystems from block devices
tries all filesystems in /etc/filesystems and possibly those in
/proc/filesystems. The regular mount binary, however, first tries
using libblkid to detect the format. Add support for doing the same
in libvirt, since Fedora's /etc/filesystems is missing many formats,
most notably ext4 which is the default filesystem Fedora uses!
* src/Makefile.am: Link libvirt_lxc to libblkid
* src/lxc/lxc_container.c: Probe filesystem format with libblkid
If we looped through /etc/filesystems trying to mount with each
type and failed all options, we forget to actually raise an
error message.
* src/lxc/lxc_container.c: Raise error if unable to detect
the filesystems. Also fix existing error message
The kernel automounter is mostly broken wrt to containers. Most
notably if you start a new filesystem namespace and then attempt
to unmount any autofs filesystem, it will typically fail with a
weird error message like
Failed to unmount '/.oldroot/sys/kernel/security':Too many levels of symbolic links
Attempting to detach the autofs mount using umount2(MNT_DETACH)
will also fail with the same error. Therefore if we get any error on
unmount()ing a filesystem from the old root FS when starting a
container, we must immediately break out and detach the entire
old root filesystem (ignoring any mounts below it).
This has the effect of making the old root filesystem inaccessible
to anything inside the container, but at the cost that the mounts
live on in the kernel until the container exits. Given that SystemD
uses autofs by default, we need LXC to be robust this scenario and
thus this tradeoff is worthwhile.
* src/lxc/lxc_container.c: Detach root filesystem if any umount
operation fails.
The /etc/filesystems file can contain a '*' on the last line to
indicate that /proc/filessystems should be tried next. We have
a check that this '*' only occurs on the last line. Unfortunately
when we then start reading /proc/filesystems, we mistakenly think
we've seen '*' in /proc/filesystems and fail
* src/lxc/lxc_container.c: Skip '*' validation when we're reading
/proc/filesystems
Only some of the return paths of lxcContainerWaitForContinue will
have set errno. In other paths we need to set it manually to avoid
the caller getting a random stale errno value
* src/lxc/lxc_container.c: Set errno in lxcContainerWaitForContinue
We already have a /var/lib/libvirt/images for OS install images.
We need a separate /var/lib/libvirt/filesystems for OS install
trees, since SELinux labelling will be different
* libvirt.spec.in: Add /var/lib/libvirt/filesystems
* src/Makefile.am: Create /var/lib/libvirt/filesystems
