The hash entry is changed from "ref" to {ref, @domains}. With this, the
caller can simply call qemuRemoveSharedDisk, without afraid of removing
the entry belongs to other domains. qemuProcessStart will obviously
benifit from it on error codepath (which calls qemuProcessStop to do
the cleanup).

Based on moving various checking into qemuAddSharedDisk, this
avoids the caller using it in wrong ways. Also this adds two
new checking for qemuCheckSharedDisk (disk device not 'lun'
and kernel doesn't support unpriv_sgio simply returns 0).

This moves the various checking into the helpers, to avoid the
callers missing the checking.

Automating a sorting check is the only way to ensure we don't
regress.  Suggested by Dan Berrange.

* src/check-symsorting.pl (check_sorting): Add a parameter,
validate that groups are in order, and that files exist.
* src/Makefile.am (check-symsorting): Adjust caller.
* src/libvirt_private.syms: Fix typo.
* src/libvirt_linux.syms: Fix file name.
* src/libvirt_vmx.syms: Likewise.
* src/libvirt_xenxs.syms: Likewise.
* src/libvirt_sasl.syms: Likewise.
* src/libvirt_libssh2.syms: Likewise.
* src/libvirt_esx.syms: Mention file name.
* src/libvirt_openvz.syms: Likewise.

Due to "feature"/"features" nasty typo, any features marked as mandatory
by one side of a migration are silently considered optional by the other
side. The following is the code that formats mandatory features in
migration cookie:

    for (i = 0 ; i < QEMU_MIGRATION_COOKIE_FLAG_LAST ; i++) {
        if (mig->flagsMandatory & (1 << i))
            virBufferAsprintf(buf, "  <feature name='%s'/>\n",
                              qemuMigrationCookieFlagTypeToString(i));
    }

Some functions were using virDomainDeviceInfo where virDevicePCIAddress
would suffice. Some were only using integers for slots and functions,
assuming the bus numbers are always 0.

Switch from virDomainDeviceInfoPtr to virDevicePCIAddressPtr:
qemuPCIAddressAsString
qemuDomainPCIAddressCheckSlot
qemuDomainPCIAddressReserveAddr
qemuDomainPCIAddressReleaseAddr

Switch from int slot to virDevicePCIAddressPtr:
qemuDomainPCIAddressReserveSlot
qemuDomainPCIAddressReleaseSlot
qemuDomainPCIAddressGetNextSlot

Deleted functions (they would take the same parameters
as ReserveAddr/ReleaseAddr do now.)
qemuDomainPCIAddressReserveFunction
qemuDomainPCIAddressReleaseFunction

Specifying ':' to suppress the error messages printed by getopt().
Then, distinguish the two types of errors.

Before:
 # virsh -c
   virsh: option requires an argument -- 'c'
   error: unsupported option '-?'. See --help.

After:
 # virsh -c
   error: option '-c' requires an argument

 # virsh -x
   error: unsupported option '-x'. See --help.

Purely mechanical (roughly, s/\n/~/; s/~~/\n/; sort by line;
s/~/\n/)

* src/libvirt_private.syms: Sort sections by header file name.

Recent renames were not reflected into the comments of
libvirt_private.syms; furthermore, since we mix private headers from
several directories into this file, knowing where the file lives
can be helpful.

* src/libvirt_private.sym: Reflect recent names.

We pass over the address/port start/end values many times so we put
them in structs.
Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org>
Signed-off-by: NLaine Stump <laine@laine.org>

Let users set the port range to be used for forward mode NAT:

...
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
...
Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org>
Signed-off-by: NLaine Stump <laine@laine.org>

Support setting which public ip to use for NAT via attribute
address in subelement <nat> in <forward>:

...
  <forward mode='nat'>
      <address start='1.2.3.4' end='1.2.3.10'/>
  </forward>
...

This will construct an iptables line using:

  '-j SNAT --to-source <start>-<end>'

instead of:

  '-j MASQUERADE'
Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org>
Signed-off-by: NLaine Stump <laine@laine.org>

We need to drop the server lock before calling virObjectUnlock(client)
since in case we had the last reference to the client, its dispose
callback would be called and that could possibly try to lock the server
and cause a deadlock. This is exactly what happens when there is only
one QEMU domain running and it is marked to be autodestroyed when the
connection dies. This results in qemuProcessAutoDestroy ->
qemuProcessStop -> virNetServerRemoveShutdownInhibition call sequence,
where the last function locks the server.

The function does not report any errors so there should be no need too
reset an existing error first. Moreover, virTypedParamsFree is mostly
called in cleanup phase where it has the potential to reset any useful
reported earlier.

It doesn't make sense to print the unit (B) only with Ki, Mi, ...
prefixes. Even those poor bytes under 1 KiB are still bytes :-)

Gcc lets you do:

int ATTRIBUTE_NONNULL(1) foo(void *param);
int foo(void *param) ATTRIBUTE_NONNULL(1);
int ATTRIBUTE_NONNULL(1) foo(void *param) { ... }

but chokes on:

int foo(void *param) ATTRIBUTE_NONNULL(1) { ... }

However, since commit eefb881d, we have intentionally been disabling
ATTRIBUTE_NONNULL because of lame gcc handling of the attribute (that
is, gcc doesn't do decent warning reporting, then compiles code that
mysteriously fails if you break the contract of the attribute, which
is surprisingly easy to do), leaving it on only for Coverity (which
does a much better job of improved static analysis when the attribute
is present).

But completely eliding the macro makes it too easy to write code that
uses the fourth syntax option, if you aren't using Coverity.  So this
patch forces us to avoid syntax errors, even when not using the
attribute under gcc.  It also documents WHY we disable the warning
under gcc, rather than forcing you to find the commit log.

* src/internal.h (ATTRIBUTE_NONNULL): Expand to empty attribute,
rather than nothing, when on gcc.

so we don't try to change uid/git to 0 when probing capabilities.

The conversion to qemuCaps dropped the ability with qemu{,-kvm} 1.2 and
newer to set the lost tick policy for the PIT. While the
-no-kvm-pit-reinjection option is depreacated, it is still supported at
least through 1.4, it is better to not lose the functionality.

udevIfaceListAllInterface() used the udev_device after it had its ref
count decremented which results in a use after free issue.

/src/lxc/lxc_protocol.[ch] is autogenerated so add it to .gitignore

Coverity found the DACGenLabel was checking for mgr == NULL after a
possible dereference; however, in order to get into the function the
virSecurityManagerGenLabel would have already dereferenced sec_managers[i]
so the check was unnecessary. Same check is made in SELinuxGenSecurityLabel.

Coverity found that commit '41b5e845' had a possible NULL dereference on
arg->data processing

Changes from commit '3178df9a' removed the need for the sa_assert(infd).

Between revision 65fb9d49 and before this patch, an upgrade of libvirt while
VMs are running and instantiating iptables filtering rules due to nwfilter
rules, may leave stray iptables rules behind when shutting VMs down.
Left-over iptables rules may look like this:

Chain FP-vnet0 (1 references)
target     prot opt source               destination         
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp spt:122
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           

[...]

Chain libvirt-out (1 references)
target     prot opt source               destination         
FO-vnet0   all  --  0.0.0.0/0            0.0.0.0/0           [goto]  PHYSDEV match --physdev-out vnet0



The reason is that the recent nwfilter code only removed filtering rules in
the libvirt-out chain that contain the --physdev-is-bridged parameter.
Older rules didn't match and were not removed.

Note that the user-defined chain FO-vnet0 could not be removed due to the
reference from the rule in libvirt-out.

Often the work around may be done through

service iptables restart
kill -SIGHUP $(pidof libvirtd)

This patch now also removes older libvirt versions' iptables rules.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Testing our backing chain handling will make it much easier to
ensure that we avoid issues in the future.  If only I had written
this test before I first caused several regressions...

* tests/virstoragetest.c: New test.
* tests/Makefile.am (test_programs): Build it.
* .gitignore: Ignore new files.

If you have a qcow2 file /path1/to/file pointed to by symlink
/path2/symlink, and pass qemu /path2/symlink, then qemu treats
a relative backing file in the qcow2 metadata as being relative
to /path2, not /path1/to.  Yes, this means that it is possible
to create a qcow2 file where the choice of WHICH directory and
symlink you access its contents from will then determine WHICH
backing file (if any) you actually find; the results can be
rather screwy, but we have to match what qemu does.

Libvirt and qemu default to creating absolute backing file
names, so most users don't hit this.  But at least VDSM uses
symlinks and relative backing names alongside the
--reuse-external flags to libvirt snapshot operations, with the
result that libvirt was failing to follow the intended chain of
backing files, and then backing files were not granted the
necessary sVirt permissions to be opened by qemu.

See https://bugzilla.redhat.com/show_bug.cgi?id=903248 for
more gory details.  This fixes a regression introduced in
commit 82507838.

I tested this patch by creating the following chain:

ls /home/eblake/Downloads/Fedora.iso # raw file for base
cd /var/lib/libvirt/images
qemu-img create -f qcow2 \
  -obacking_file=/home/eblake/Downloads/Fedora.iso,backing_fmt=raw one
mkdir sub
cd sub
ln -s ../one onelink
qemu-img create -f qcow2 \
  -obacking_file=../sub/onelink,backing_fmt=qcow2 two
mv two ..
ln -s ../two twolink
qemu-img create -f qcow2 \
  -obacking_file=../sub/twolink,backing_fmt=qcow2 three
mv three ..
ln -s ../three threelink

then pointing my domain at /var/lib/libvirt/images/sub/threelink.
Prior to this patch, I got complaints about missing backing
files; afterwards, I was able to verify that the backing chain
(and hence DAC and SELinux relabels) of the entire chain worked.

* src/util/virstoragefile.h (_virStorageFileMetadata): Add
directory member.
* src/util/virstoragefile.c (absolutePathFromBaseFile): Drop,
replaced by...
(virFindBackingFile): ...better function.
(virStorageFileGetMetadataInternal): Add an argument.
(virStorageFileGetMetadataFromFD, virStorageFileChainLookup)
(virStorageFileGetMetadata): Update callers.

Prior to this patch, we had the callchains:
external users
  \-> virStorageFileGetMetadataFromFD
      \-> virStorageFileGetMetadataFromBuf
virStorageFileGetMetadataRecurse
  \-> virStorageFileGetMetadataFromFD
      \-> virStorageFileGetMetadataFromBuf

However, a future patch wants to add an additional parameter to
the bottom of the chain, for use by virStorageFileGetMetadataRecurse,
without affecting existing external callers.  Since there is only a
single caller of the internal function, we can repurpose it to fit
our needs, with this patch giving us:

external users
  \-> virStorageFileGetMetadataFromFD
      \-> virStorageFileGetMetadataInternal
virStorageFileGetMetadataRecurse /
  \-> virStorageFileGetMetadataInternal

* src/util/virstoragefile.c (virStorageFileGetMetadataFromFD):
Move most of the guts...
(virStorageFileGetMetadataFromBuf): ...here, and rename...
(virStorageFileGetMetadataInternal): ...to this.
(virStorageFileGetMetadataRecurse): Use internal helper.

virStorageFileGetMetadataFromFD is the only caller of
virStorageFileGetMetadataFromBuf; and it doesn't care about the
difference between a return of 0 (total success) or 1
(metadata was inconsistent, but pointer was populated as best
as possible); only about a return of -1 (could not read metadata
or out of memory).  Changing the return type, and normalizing
the variable names used, will make merging the functions easier
in the next commit.

* src/util/virstoragefile.c (virStorageFileGetMetadataFromBuf):
Change return value, and rename some variables.
(virStorageFileGetMetadataFromFD): Rename some variables.

No semantic change; done so the next patch doesn't need a forward
declaration of a static function.

* src/util/virstoragefile.c (virStorageFileProbeFormatFromBuf):
Hoist earlier.

More mingw build failures:

  CCLD     libvirt-lxc.la
/usr/lib64/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld: cannot find libvirt_lxc.def: No such file or directory

  CC       virportallocatortest-virportallocatortest.o
../../tests/virportallocatortest.c: In function 'main':
../../tests/virportallocatortest.c:195:1: error: implicit declaration of function 'setenv' [-Werror=implicit-function-declaration]

* src/Makefile.am (GENERATED_SYM_FILES): Also generate
libvirt_lxc.def.
* bootstrap.conf (gnulib_modules): Import setenv.

Commits 20253560 and ba72cb12 introduced typos.

* src/util/virpci.c (virPCIIsVirtualFunction) [!__linux__]: Fix
function name.
* src/util/virutil.c (virGetDeviceID): Fix attribute spelling.

  CC       libvirt_util_la-vircommand.lo
../../src/util/vircommand.c:2358:1: error: 'virCommandHandshakeChild' defined but not used [-Werror=unused-function]

The function is only implemented inside #ifndef WIN32.

* src/util/vircommand.c (virCommandHandshakeChild): Hoist earlier,
so that win32 build doesn't hit an unused forward declaration.

No need to use HAVE_REGEX_H - our use of gnulib guarantees that
the header exists and works, regardless of platform.  Similarly,
we can unconditionally assume a compiling <sys/wait.h> (although
the mingw version of this header is not full-featured).

* src/storage/storage_backend.c: Drop useless conditional.
* tests/testutils.c: Likewise.

virCommand was previously calling virSetUIDGID() to change the uid and
gid of the child process, then separately calling
virSetCapabilities(). This did not work if the desired uid was != 0,
since a setuid to anything other than 0 normally clears all
capabilities bits.

The solution is to use the new virSetUIDGIDWithCaps(), sending it the
uid, gid, and capabilities bits. This will get the new process setup
properly.

Since the static functions virSetCapabilities() and
virClearCapabilities are no longer called, they have been removed.

NOTE: When combined with "filecap $path-to-qemu sys_rawio", this patch
will make CAP_SYS_RAWIO (which is required for passthrough of generic
scsi commands to a guest - see commits e8daeeb1, 177db087, 397e6a70, and
74e03496) be retained by qemu when necessary. Apparently that
capability has been broken for non-root qemu ever since it was
originally added.

Normally when a process' uid is changed to non-0, all the capabilities
bits are cleared, even those explicitly set with calls to
capng_update()/capng_apply() made immediately before setuid. And
*after* the process' uid has been changed, it no longer has the
necessary privileges to add capabilities back to the process.

In order to set a non-0 uid while still maintaining any capabilities
bits, it is necessary to either call capng_change_id() (which
unfortunately doesn't currently call initgroups to setup auxiliary
group membership), or to perform the small amount of calisthenics
contained in the new utility function virSetUIDGIDWithCaps().

Another very important difference between the capabilities
setting/clearing in virSetUIDGIDWithCaps() and virCommand's
virSetCapabilities() (which it will replace in the next patch) is that
the new function properly clears the capabilities bounding set, so it
will not be possible for a child process to set any new
capabilities.

A short description of what is done by virSetUIDGIDWithCaps():

1) clear all capabilities then set all those desired by the caller (in
capBits) plus CAP_SETGID, CAP_SETUID, and CAP_SETPCAP (which is needed
to change the capabilities bounding set).

2) call prctl(), telling it that we want to maintain current
capabilities across an upcoming setuid().

3) switch to the new uid/gid

4) again call prctl(), telling it we will no longer want capabilities
maintained if this process does another setuid().

5) clear the capabilities that we added to allow us to
setuid/setgid/change the bounding set (unless they were also requested
by the caller via the virCommand API).

Because the modification/maintaining of capabilities is intermingled
with setting the uid, this is necessarily done in a single function,
rather than having two independent functions.

Note that, due to the way that effective capabilities are computed (at
time of execve) for a process that has uid != 0, the *file*
capabilities of the binary being executed must also have the desired
capabilities bit(s) set (see "man 7 capabilities"). This can be done
with the "filecap" command. (e.g. "filecap /usr/bin/qemu-kvm sys_rawio").

This is an interim measure to make sure everything still works in this
order. The next step will be to perform capabilities drop and
setuid/gid as a single operation (which is the only way to keep any
capabilities when switching to a non-root uid).