When reporting a system error (VIR_ERR_SYSTEM_ERROR) via
virReportSystemError, we should copy the errno value into
the 'int1' field of the virErrorPtr struct. This allows
callers to detect certain errno conditions & discard the
error

* src/util/virterror.c: Place errno value in int1 field

ensures that initialization will always take place when it is
needed, and guarantees it only occurs once. The problem is that
the code to setup a global initializer with proper error
propagation is tedious. This introduces VIR_ONCE_GLOBAL_INIT
macro to simplify this.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Detected on Cygwin.  Broken in commit 387117ad.

* src/util/virnetdev.c (virNetDevValidateConfig)
(virNetDevReplaceNetConfig): Fix prototypes.
* src/util/virnetlink.c (virNetlinkEventAddClient)
(virNetlinkEventRemoveClient): Likewise.

This removes nearly all the per-file error reporting macros
from the code in src/util/. A few custom macros remain for the
case, where the file needs to report errors with a variety of
different codes or parameters
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virnetdevtap.c and viruri.c files had two error report
messages which were not annotated with _(...)
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Nearly every source file does something like

  #define VIR_FROM_THIS VIR_FROM_FOO
  #define virFooReportErorr(code, ...) \
     virReportErrorHelper(VIR_FROM_THIS, code,  __FILE__,    \
                          __FUNCTION__, __LINE__, \
                          __VA_ARGS__)

This creates needless duplication and inconsistent error
reporting function names in each file. It is trivial to
just have virterror_internal.h provide a virReportError
macro that is equivalent

* src/util/virterror_internal.h: Define virReportError(code, ...)
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce new members in the virMacAddr 'class'
- virMacAddrSet: set virMacAddr from a virMacAddr
- virMacAddrSetRaw: setting virMacAddr from raw 6 byte MAC address buffer
- virMacAddrGetRaw: writing virMacAddr into raw 6 byte MAC address buffer
- virMacAddrCmp: comparing two virMacAddr
- virMacAddrCmpRaw: comparing a virMacAddr with a raw 6 byte MAC address buffer

then replace raw MAC addresses by replacing

- 'unsigned char *' with virMacAddrPtr
- 'unsigned char ... [VIR_MAC_BUFLEN]' with virMacAddr

and introduce usage of above functions where necessary.

When building with --disable-debug, VIR_DEBUG expands to a nop.
But parameters to VIR_DEBUG can be variables that are passed only
to VIR_DEBUG. In the case the building system complains about unused
variables.

All the callers of virDirCreate are updated incidentally.

Instead of changing the existed virFileMakePath to accept mode
argument and modifying a pile of its uses, this patch introduces
virFileMakePathWithMode, and use it instead of mkdir() to create
the readline history dir.

Commit 9612e4b2 introduced a typo and unused variable that break
non-Linux builds.

* src/util/virfile.c (virFileLoopDeviceAssociate): Fix syntax error.

While it is not currently used elsewhere in libvirt, the code
for finding a free loop device & associating a file with it
is not LXC specific. Move it into the viffile.{c,h} file where
potentially shared code is more commonly kept.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Hello,

This is a patch to fix vm's outbound traffic control problem.

Currently, vm's outbound traffic control by libvirt doesn't go well.
This problem was previously discussed at libvir-list ML, however
it seems that there isn't still any answer to the problem.
http://www.redhat.com/archives/libvir-list/2011-August/msg00333.html

I measured Guest(with virtio-net) to Host TCP throughput with the
command "netperf -H".
Here are the outbound QoS parameters and the results.

outbound average rate[kilobytes/s] : Guest to Host throughput[Mbit/s]
======================================================================
1024  (8Mbit/s)                    : 4.56
2048  (16Mbit/s)                   : 3.29
4096  (32Mbit/s)                   : 3.35
8192  (64Mbit/s)                   : 3.95
16384 (128Mbit/s)                  : 4.08
32768 (256Mbit/s)                  : 3.94
65536 (512Mbit/s)                  : 3.23

The outbound traffic goes down unreasonably and is even not controled.

The cause of this problem is too large mtu value in "tc filter" command run by
libvirt. The command uses burst value to set mtu and the burst is equal to
average rate value if it's not set. This value is too large. For example
if the average rate is set to 1024 kilobytes/s, the mtu value is set to 1024
kilobytes. That's too large compared to the size of network packets.
Here libvirt applies tc ingress filter to Host's vnet(tun) device.
Tc ingress filter is implemented with TBF(Token Buckets Filter) algorithm. TBF
uses mtu value to calculate the amount of token consumed by each packet. With too
large mtu value, the token consumption rate is set too large. This leads to
token starvation and deterioration of TCP throughput.

Then, should we use the default mtu value 2 kilobytes?
The anser is No, because Guest with virtio-net device uses 65536 bytes
as mtu to transmit packets to Host, and the tc filter with the default mtu
value 2k drops packets whose size is larger than 2k. So, the most packets
is droped and again leads to deterioration of TCP throughput.

The appropriate mtu value is 65536 bytes which is equal to the maximum value
of network interface device defined in <linux/netdevice.h>. The value is
not so large that it causes token starvation and not so small that it
drops most packets.
Therefore this patch set the mtu value to 64kb(== 65535 bytes).

Again, here are the outbound QoS parameters and the TCP throughput with
the libvirt patched.

outbound average rate[kilobytes/s] : Guest to Host throughput[Mbit/s]
======================================================================
1024  (8Mbit/s)                    : 8.22
2048  (16Mbit/s)                   : 16.42
4096  (32Mbit/s)                   : 32.93
8192  (64Mbit/s)                   : 66.85
16384 (128Mbit/s)                  : 133.88
32768 (256Mbit/s)                  : 271.01
65536 (512Mbit/s)                  : 547.32

The outbound traffic conforms to the given limit.

Thank you,
Signed-off-by: NEiichi Tsukata <eiichi.tsukata.xh@hitachi.com>

The ignore_value macro is used across libvirt. This patch includes it in
the internal header and cleans all other includes.

In order to retrieve some sysinfo data we need to parse /proc/sysinfo and
/proc/cpuinfo.
Signed-off-by: NThang Pham <thang.pham@us.ibm.com>
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

Some GNULIB headers (eg unistd.h) will often need to include
winsock2.h for various symbols. There is a rule that winsock2.h
must be included before windows.h. This means that any file
which does

  #ifdef WIN32
  #include <windows.h>
  #endif
  #include <unistd.h>

is potentially broken. A simple rule is that /all/ includes of
windows.h must be matched with a preceding include of winsock2.h
regardless of whether unistd.h is used currently
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

src/util/util.c: virFileOpenAs.

To facilitate future troubleshooting add a bunch more debugging
statements into important startup parts of libvirt

A core use case of the hook scripts is to be able to do things
to a guest's network configuration. It is possible to hook into
the 'start' operation for a QEMU guest which runs just before
the guest is started. The TAP devices will exist at this point,
but the QEMU process will not. It can be desirable to have a
'started' hook too, which runs once QEMU has started.

If libvirtd is restarted it will re-populate firewall rules,
but there is no QEMU hook to trigger for existing domains.
This is solved with a 'reconnect' hook.

Finally, if attaching to an external QEMU process there needs
to be an 'attach' hook script.

This all also applies to the LXC driver

* docs/hooks.html.in: Document new operations
* src/util/hooks.c, src/util/hooks.c: Add 'started', 'reconnect'
  and 'attach' operations for QEMU. Add 'prepare', 'started',
  'release' and 'reconnect' operations for LXC
* src/lxc/lxc_driver.c: Add hooks for 'prepare', 'started',
  'release' and 'reconnect' operations
* src/qemu/qemu_process.c: Add hooks for 'started', 'reconnect'
  and 'reconnect' operations

Right now, the only way to get at the contents of a virBuffer is
to destroy it.  But there are cases in my upcoming patches where
peeking at the contents makes life easier.  I suppose this does
open up the potential for bad code to dereference a stale pointer,
by disregarding the docs that the return value is invalid on the
next virBuf operation, but such is life.

* src/util/buf.h (virBufferCurrentContent): New declaration.
* src/util/buf.c (virBufferCurrentContent): Implement it.
* src/libvirt_private.syms (buf.h): Export it.
* tests/virbuftest.c (testBufAutoIndent): Test it.

When libvirtd forks off a new child, the child then calls virLogReset(),
which ends up closing file descriptors used as log outputs. However, we
recently started logging closed file descriptors, which means we need to
lock logging mutex which was already locked by virLogReset(). We don't
really want to log anything when we are in the process of closing log
outputs.

There is a theoretical problem of an extreme bug where we can get
into deadlock due to command handshaking.  Thanks to a pair of pipes,
we have a situation where the parent thinks the child reported an
error and is waiting for a message from the child to explain the
error; but at the same time the child thinks it reported success
and is waiting for the parent to acknowledge the success; so both
processes are now blocked.

Thankfully, I don't think this deadlock is possible without at
least one other bug in the code, but I did see exactly that sort
of situation prior to commit da831afc - I saw a backtrace where a
double close bug in the parent caused the parent to read from the
wrong fd and assume the child failed, even though the child really
sent success.

This potential deadlock is not quite like commit 858c2476 (a deadlock
due to multiple readers on one pipe preventing a write from completing),
although the solution is similar - always close unused pipe fds before
blocking, rather than after.

* src/util/command.c (virCommandHandshakeWait): Close unused fds
sooner.

Noticed during the previous commit.

* src/util/command.c: Fix some spacing and break long lines.

It is possible to deadlock libvirt by having a domain with XML
longer than PIPE_BUF, and by writing a hook script that closes
stdin early.  This is because libvirt was keeping a copy of the
child's stdin read fd open, which means the write fd in the
parent will never see EPIPE (remember, libvirt should always be
run with SIGPIPE ignored, so we should never get a SIGPIPE signal).
Since there is no error, libvirt blocks waiting for a write to
complete, even though the only reader is also libvirt.  The
solution is to ensure that only the child can act as a reader
before the parent does any writes; and then dealing with the
fallout of dealing with EPIPE.

Thankfully, this is not a security hole - since the only way to
trigger the deadlock is to install a custom hook script, anyone
that already has privileges to install a hook script already has
privileges to do any number of other equally disruptive things
to libvirt; it would only be a security hole if an unprivileged
user could install a hook script to DoS a privileged user.

* src/util/command.c (virCommandRun): Close parent's copy of child
read fd earlier.
(virCommandProcessIO): Don't let EPIPE be fatal; the child may
be done parsing input.
* tests/commandhelper.c (main): Set up a SIGPIPE situation.
* tests/commandtest.c (test20): Trigger it.
* tests/commanddata/test20.log: New file.

EBADF errors are logged as warnings as they normally indicate a double
close bug. This patch also provides VIR_MASS_CLOSE helper to be user in
the only case of mass close after fork when EBADF should rather be
ignored.

Probably a result of copy&paste...

We should not set *outfd or *errfd if virExecWithHook() failed
because the caller may close these fds.

Bug present since v0.4.5 (commit 60ed1d2a).

KAMEZAWA Hiroyuki reported a nasty double-free bug when virCommand
is used to convert a string into input to a child command.  The
problem is that the poll() loop of virCommandProcessIO would close()
the write end of the pipe in order to let the child see EOF, then
the caller virCommandRun() would also close the same fd number, with
the second close possibly nuking an fd opened by some other thread
in the meantime.  This in turn can have all sorts of bad effects.

The bug has been present since the introduction of virCommand in
commit f16ad06f.

This is based on his first attempt at a patch, at
https://bugzilla.redhat.com/show_bug.cgi?id=823716

* src/util/command.c (_virCommand): Drop inpipe member.
(virCommandProcessIO): Add argument, to avoid closing caller's fd
without informing caller.
(virCommandRun, virCommandNewArgs): Adjust clients.

Currently, we are logging only one side of pipes we
create in virCommandRequireHandshake(); This is enough
in cases where pipe2() returns two consecutive FDs. However,
it is not guaranteed and it may return any FDs.
Therefore, it's wise to log the other ends as well.

To ensure consistent error reporting of invalid arguments,
provide a number of predefined helper methods & macros.

 - An arg which must not be NULL:

   virCheckNonNullArgReturn(argname, retvalue)
   virCheckNonNullArgGoto(argname, label)

 - An arg which must be NULL

   virCheckNullArgGoto(argname, label)

 - An arg which must be positive (ie 1 or greater)

   virCheckPositiveArgGoto(argname, label)

 - An arg which must not be 0

   virCheckNonZeroArgGoto(argname, label)

 - An arg which must be zero

   virCheckZeroArgGoto(argname, label)

 - An arg which must not be negative (ie 0 or greater)

   virCheckNonNegativeArgGoto(argname, label)

* src/libvirt.c, src/libvirt-qemu.c,
  src/nodeinfo.c, src/datatypes.c: Update to use
  virCheckXXXX macros
* po/POTFILES.in: Add libvirt-qemu.c and virterror_internal.h
* src/internal.h: Define macros for checking invalid args
* src/util/virterror_internal.h: Define macros for reporting
  invalid args
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add an impl of +virGetUserRuntimeDirectory, virGetUserCacheDirectory
virGetUserConfigDirectory and virGetUserDirectory for Win32 platform.
Also create stubs for non-Win32 platforms which lack getpwuid_r()

In adding these two helpers were added virFileIsAbsPath and
virFileSkipRoot, along with some macros VIR_FILE_DIR_SEPARATOR,
VIR_FILE_DIR_SEPARATOR_S, VIR_FILE_IS_DIR_SEPARATOR,
VIR_FILE_PATH_SEPARATOR, VIR_FILE_PATH_SEPARATOR_S

All this code was adapted from GLib2 under terms of LGPLv2+ license.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Remove the uid param from virGetUserConfigDirectory,
virGetUserCacheDirectory, virGetUserRuntimeDirectory,
and virGetUserDirectory

These functions were universally called with the
results of getuid() or geteuid(). To make it practical
to port to Win32, remove the uid parameter and hardcode
geteuid()
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a VIR_ERR_DOMAIN_LAST sentinel for virErrorDomain and
replace the virErrorDomainName function by a VIR_ENUM_IMPL

In the process the naming of error domains is sanitized

* src/util/virterror.c: Use VIR_ENUM_IMPL for converting
  error domains to strings
* include/libvirt/virterror.h: Add VIR_ERR_DOMAIN_LAST

The libvirt_private.syms file exports virNetlinkEventServiceLocalPid
so there needs to be a no-op stub for Win32 to avoid linker errors
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

I'm tired of writing:

bool sep = false;
while (...) {
    if (sep)
       virBufferAddChar(buf, ',');
    sep = true;
    virBufferAdd(buf, str);
}

This makes it easier, allowing one to write:

while (...)
    virBufferAsprintf(buf, "%s,", str);
virBufferTrim(buf, ",", -1);

to trim any remaining comma.

* src/util/buf.h (virBufferTrim): Declare.
* src/util/buf.c (virBufferTrim): New function.
* tests/virbuftest.c (testBufTrim): Test it.

We were being lazy - virnetlink.c was getting uint32_t as a
side-effect from glibc 2.14's <unistd.h>, but older glibc 2.11
does not provide uint32_t from <unistd.h>.  In fact, POSIX states
that <unistd.h> need only provide intptr_t, not all of <stdint.h>,
so the bug really is ours.  Reported by Jonathan Alescio.

* src/util/virnetlink.h: Include <stdint.h>.

This involves setting the cpuacct cgroup to a per-vcpu granularity,
as well as summing the each vcpu accounting into a common array.
Now that we are reading more than one cgroup file, we double-check
that cpus weren't hot-plugged between reads to invalidate our
summing.
Signed-off-by: NEric Blake <eblake@redhat.com>