On RHEL 5, with gcc 4.1.2:

rpc/virnetsaslcontext.c: In function 'virNetSASLSessionUpdateBufSize':
rpc/virnetsaslcontext.c:396: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

* src/rpc/virnetsaslcontext.c (virNetSASLSessionUpdateBufSize):
Use a union to work around gcc warning.

qemuMigrationUpdateJobStatus (called in a loop by migration
and save tasks) uses qemuDomainObjEnterMonitorWithDriver;
however, that function ended up starting a nested job without
releasing the driver.

Since no one else is making nested calls, we can inline the
internal functions to properly track driver_locked.

* src/qemu/qemu_domain.h (qemuDomainObjBeginNestedJob)
(qemuDomainObjBeginNestedJobWithDriver)
(qemuDomainObjEndNestedJob): Drop unused prototypes.
* src/qemu/qemu_domain.c (qemuDomainObjEnterMonitorInternal):
Reflect driver lock to nested job.
(qemuDomainObjBeginNestedJob)
(qemuDomainObjBeginNestedJobWithDriver)
(qemuDomainObjEndNestedJob): Drop unused functions.

As written in virStorageFileGetMetadataFromFD decription, caller
must free metadata after use. Qemu driver miss this and therefore
leak metadata which can grow to huge mem leak if somebody query
for blockInfo a lot.

Because we do support flags for virDomainSetBlkioParameters and
virDomainGetBlkioParameters, update appropriate description as well.

* tools/virsh.c: avoid memory leak in cmdVolPath.
* src/libvirt.c: Add doc for virStorageVolGetPath to tell one
  must free() the returned path after use.

* how to reproduce?

% dd if=/dev/zero of=/var/lib/libvirt/images/foo.img count=1 bs=10M
% virsh pool-refresh default
% valgrind -v --leak-check=full virsh vol-path --vol \
/var/lib/libvirt/images/foo.img

* actual results:

Detected in valgrind run:

==16436== 32 bytes in 1 blocks are definitely lost in loss record 7 of 22
==16436==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==16436==    by 0x386A314B3D: xdr_string (in /lib64/libc-2.12.so)
==16436==    by 0x3DF8CD770D: xdr_remote_nonnull_string (remote_protocol.c:3
==16436==    by 0x3DF8CD7EC8: xdr_remote_storage_vol_get_path_ret
% virsh pool-refresh default
% valgrind -v --leak-check=full virsh vol-path --vol \
/var/lib/libvirt/images/foo.img
Signed-off-by: NAlex Jia <ajia@redhat.com>

The error in getCompressionType will never be reported, change
the errors codes into warning (VIR_WARN("%s", _(foo)); doesn't break
syntax-check rule), and also improve the docs in qemu.conf to tell
user the truth.

* src/qemu/THREADS.txt: Fix problems with typos, grammar, and
outdated examples.

Add a new helper remoteFreeTypedParameters and teach the generator
to add it to the cleanup section.

https://bugzilla.redhat.com/show_bug.cgi?id=725322

This doesn't abort migration job in any phase, yet.

Call qemu monitor command directly within a special job that is only
allowed during outgoing migration.

Call qemu monitor command directly within a special job that is only
allowed during outgoing migration.

Like other query commands, this can now be called directly during
migration.

Like other query commands, this can now be called directly during
migration.

Make MIGRATION_OUT use the new helper methods.

This also introduces new protection to migration v3 process: the
migration job is held from Begin to Confirm to avoid changes to a domain
during migration (esp. between Begin and Perform phases). This change is
automatically applied to p2p and tunneled migrations. For normal
migration, this requires support from a client. In other words, if an
old (pre 0.9.4) client starts normal migration of a domain, the domain
will not be protected against changes between Begin and Perform steps.

Make MIGRATION_IN use the new helper methods.

This patch introduces several helper methods to deal with jobs and
phases during migration in a simpler manner.

Without this, a configure built by autoconf 2.59 was broken when
trying to detect which compiler warning flags were supported.

* .gnulib: Update to latest, for warnings.m4 fix.
* bootstrap.conf: Add fclose explicitly, to match recent gnulib
implicit dependency changes.
* src/qemu/qemu_conf.c (includes): Drop unused include.
* src/uml/uml_conf.c (include): Likewise.
Reported by Daniel P. Berrange.

Every DomainNetDef has a bandwidth, as does every portgroup.
Whenever a DomainNetDef of type NETWORK is about to be used, a call is
made to networkAllocateActualDevice(). This function chooses the "best"
bandwidth object and places it in the DomainActualNetDef.
From that point on, whenever some code needs to use the bandwidth data
for the interface, it's retrieved with virDomainNetGetActualBandwidth(),
which will always return the "best" info as determined in the
previous step.

Fix the build if HAVE_AVAHI is not defined.

When an incoming RPC message is ready for processing,

  virNetServerClientDispatchRead()

will invoke the 'dispatchFunc' callback. This is set to

  virNetServerDispatchNewMessage

This function puts the message + client in a queue for processing by the thread
pool. The thread pool worker function is

  virNetServerHandleJob

The first thing this does is acquire an extra reference on the 'client'.

Unfortunately, between the time the message+client are put on the thread pool
queue, and the time the worker runs, the client object may have had its last
reference removed.

We clearly need to add the reference to the client object before putting the
client on the processing queue

* src/rpc/virnetserverclient.c: Add a reference to the client when
  invoking the dispatch function
* src/rpc/virnetserver.c: Don't acquire a reference to the client
  when in the worker thread

The cpu bandwidth is applied at the vcpu group level. We should apply it
at the vm group level too, because the vm may do heavy I/O, and it will affect
the other vm.

We apply cpu bandwidth at the vcpu and the vm group level, so we must ensure
that max(child_quota) <= parent_quota when we modify cpu bandwidth.

Introduced by commit 239322cb, reported by Ruben Kerkhof.

The virNetSASLContext, virNetSASLSession, virNetTLSContext and
virNetTLSSession classes previously relied in their owners
(virNetClient / virNetServer / virNetServerClient) to provide
locking protection for concurrent usage. When virNetSocket
gained its own locking code, this invalidated the implicit
safety the SASL/TLS modules relied on. Thus we need to give
them all explicit locking of their own via new mutexes.

* src/rpc/virnetsaslcontext.c, src/rpc/virnettlscontext.c: Add
  a mutex per object

When setting up a server socket, we must skip EADDRINUSE errors
from bind, since the IPv6 socket bind may have already bound to
the IPv4 socket too. If we don't manage to bind to any sockets
at all though, we should then report the EADDRINUSE error as
normal.

This fixes the case where libvirtd would not exit if some other
program was listening on its TCP/TLS ports.

* src/rpc/virnetsocket.c: Report EADDRINUSE

* src/rpc/virnetserver.c: Free mDNS object

* src/rpc/virnetservermdns.c: Fix leaks

Now that virDomainSetVcpusFlags knows about VIR_DOMAIN_AFFECT_CURRENT,
so should virDomainGetVcpusFlags.

Unfortunately, the virsh counterpart 'virsh vcpucount' has already
commandeered --current for a different meaning, so teaching virsh
to expose this in the next patch will require a bit of care.

* src/libvirt.c (virDomainGetVcpusFlags): Allow
VIR_DOMAIN_AFFECT_CURRENT.
* src/libxl/libxl_driver.c (libxlDomainGetVcpusFlags): Likewise.
* src/qemu/qemu_driver.c (qemudDomainGetVcpusFlags): Likewise.
* src/test/test_driver.c (testDomainGetVcpusFlags): Likewise.
* src/xen/xen_driver.c (xenUnifiedDomainGetVcpusFlags): Likewise.

Although most functions in libvirt return 0 on success and < 0 on
failure, there are a few functions lingering around that return errno
(a positive value) on failure, and sometimes code calling those
functions incorrectly assumes the <0 standard. I noticed one of these
the other day when auditing networkStartDhcpDaemon after Guido Gunther
found a place where success was improperly returned on failure (that
patch has been acked and is pending a push). The problem was that it
expected the return value from virFileReadPid to be < 0 on failure,
but it was actually positive (it was also neglected to set the return
code in this case, similar to the bug found by Guido).

This all led to the fact that *all* of the virFile*Pid functions in
util.c are returning errno on failure. This patch remedies that
problem by changing them all to return -errno on failure, and makes
any necessary changes to callers of the functions. (In the meantime, I
also properly set the return code on failure of virFileReadPid in
networkStartDhcpDaemon).

While we checked the return value we didn't maks sure ret != 0 which
resulted in dnsmasq errors being ignored.

In the XML file we now have

  <cputune>
    <shares>1024</shares>
    <period>90000</period>
    <quota>0</quota>
  </cputune>

But the schedinfo parameter are being named

 cpu_shares: 1024
 cfs_period: 90000
 cfs_quota: 0

The period/quota is per-vcpu value, so these new tunables should be named
'vcpu_period' and 'vcpu_quota'.

These function executes 'tc' with appropriate arguments to set
desired QoS setting on interface or bridge during its creation.

These functions parse given XML node and return pointer to the
output. Unknown elements are silently ignored. Attributes must
be integer and must fit in unsigned long long.

Free function frees elements of virBandwidth structure.

The new listenNetwork attribute needs to learn an IP address based on a
named network. This patch provides a function networkGetNetworkAddress
which provides that.

Some networks have an IP address explicitly in their configuration
(ie, those with a forward type of "none", "route", or "nat"). For
those, we can just return the IP address from the config.

The rest will have a physical device associated with them (either via
<bridge name='...'/>, <forward ... dev='...'/>, or possibly via a pool
of interfaces inside the network's <forward> element) and we will need
to ask the kernel for a current IP address of that device (via the
newly added ifaceGetIPAddress)

If networkGetNetworkAddress encounters an error while trying to learn
the address for a network, it will return -1. In the case that libvirt
has been compiled without the network driver, the call is a macro
which reduces to -2. This allows differentiating between a failure of
the network driver, and its complete absence.

This function uses ioctl(SIOCGIFADDR), which limits it to returning
the first IPv4 address of an interface, but that's what we want right
now (the place we're going to use the address only accepts one).