If an early dispatch check caused a jump to the 'cleanup' branch
then virTypeParamsFree() would be called with an uninitialized
'nparams' variable. Fortunately 'params' is initialized to NULL,
so the uninitialized 'nparams' variable would not be used.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 31dbbb66)

Commit 776d49f4 added a static function that is only called
conditionally; leading to this compile error on mingw:

  CC       libvirt_util_la-virprocess.lo
../../src/util/virprocess.c:624:26: error: 'struct rlimit' declared inside parameter list [-Werror]
../../src/util/virprocess.c:624:26: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
../../src/util/virprocess.c:622:1: error: 'virProcessPrLimit' defined but not used [-Werror=unused-function]

* src/util/virprocess.c (virProcessPrLimit): Only declare
virProcessPrLimit when used.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 05f79a38)

The F_DUPFD_CLOEXEC operation with fcntl() expects a single
int argument, specifying the minimum FD number for the newly
dup'd file descriptor. We were not specifying that causing
random stack data to be accessed as the FD number. Sometimes
that worked, sometimes it didn't.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit d6670a64)

https://bugzilla.redhat.com/show_bug.cgi?id=924501 tracks a
problem that occurs if uid 107 is already in use at the time
libvirt is first installed.  In response that problem, Fedora
packaging guidelines were recently updated.  This fixes the
spec file to comply with the new guidelines:
https://fedoraproject.org/wiki/Packaging:UsersAndGroups

* libvirt.spec.in (daemon): Follow updated Fedora guidelines.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit a2584d58)

'make distcheck' complained:

ERROR: files left in build directory after distclean:
./python/libvirt.pyc
./tests/commandhelper.log

Problems introduced in commits f0154959 and 25ea8e47 (both v1.0.3).

* tests/commandtest.c (test21): Check (and clean) log file.
* tests/commanddata/test21.log: New file.
* python/Makefile.am (CLEANFILES): Clean up compiled python files.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit c21c38d7)

On a mingw build, 'make distcheck' fails with:

  GEN      libvirt_qemu.def
make[3]: *** No rule to make target `../../src/libvirt_lxc.syms', needed by `libvirt_lxc.def'.  Stop.

I traced it to a missing entry in EXTRA_DIST.  But rather than keep
the entire list in sync, it is easier to list the three syms files
that drive .so files directly, and then reuse existing makefile
variables for the remaining files (that is, I validated that all
remaining files are added to SYM_FILES, possibly via USED_SYM_FILES,
according to makefile conditionals).

Problem introduced in commit 3d1596b0 (v1.0.2).

* src/Makefile.am (EXTRA_DIST): Ensure all syms files are shipped.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit ed11ab93)

I must have looked at this a couple dozen times before I noticed it
had "!=" instead of "==". Not doing this setup prevented qemu from
doing anything with the vfio group device.
(cherry picked from commit 52ba0f6e)

The libvirt 1.0.5 tarball is missing a file which renders 'make
check' broken; first reported on list by Guido Günther.

* python/Makefile.am (EXTRA_DIST): Hoist sanitytest.py out of
HAVE_PYTHON conditional.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 5a3487da)

introduced by dcf97846

To trigger this cppi needs to be installed.
(cherry picked from commit ca75c443)

introduced by dcf97846
(cherry picked from commit a1365d73)

This should resolve https://bugzilla.redhat.com/show_bug.cgi?id=958907

Recent new addition of code to read/write active network state to the
NETWORK_STATE_DIR in the network driver broke startup for
qemu:///session. The network driver had several state file paths
hardcoded to /var, which could never possibly work in session mode.

This patch modifies *all* state files to use a variable string that is
set differently according to whether or not we're running
privileged. (It turns out that logDir was never used, so it's been
completely eliminated.)

There are very definitely other problems preventing dnsmasq and radvd
from running in non-privileged mode, but it's more consistent to have
the directories used by them be determined in the same fashion.

NB: I've noted before that the network driver is storing its state
(including dnsmasq and radvd state) in /var/lib, while qemu stores its
state in /var/run. It would probably have been better if the two
matched, but it's been this way for a long time, and changing it would
break running installations during an upgrade, so it's best to just
leave it as it is.
(cherry picked from commit 2ffd87d8)

Conflicts:
	src/network/bridge_driver.c - code removed by this patch had
                                      been modified upstream.

* configure.ac docs/news.html.in libvirt.spec.in: updated for the release
* po/*.po*: pulled and merged a number of new localization updates

When MAXHOSTNAMELEN is set we have to take it's value into account.
Otherwise the build fails on kFreeBSD (FreeBSD kernel and GNU userland)

virPCIDeviceReattach and virPCIDeviceUnbindFromStub (called by
virPCIDeviceReattach) had previously required the name of the stub
driver as input. This is unnecessary, because the name of the driver
the device is currently bound to can be found by looking at the link:

  /sys/bus/pci/dddd:bb:ss.ff/driver

Instead of requiring that the name of the expected stub driver name
and only unbinding if that one name is matched, we no longer take a
driver name in the arglist for either of these
functions. virPCIDeviceUnbindFromStub just compares the name of the
currently bound driver to a list of "well known" stubs (right now
contains "pci-stub" and "vfio-pci" for qemu, and "pciback" for xen),
and only performs the unbind if it's one of those devices.

This allows virsh nodedevice-reattach to work properly across a
libvirtd restart, and fixes a couple of cases where we were
erroneously still hard-coding "pci-stub" as the drive name.

For some unknown reason, virPCIDeviceReattach had been calling
modprobe on the stub driver prior to unbinding the device. This was
problematic because we no longer know the name of the stub driver in
that function. However, it is pointless to probe for the stub driver
at that time anyway - because the device is bound to the stub driver,
we are guaranteed that it is already loaded, and so that call to
modprobe has been removed.

Conditional BuildRequires: should be at the top level, rather
than appearing in conditional sub-package sections.  This
appears to be the only offender.

* libvirt.spec.in (BuildRequires): Move libblkid-devel into
correct area.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit cc6d19f3 added text containing "<code>snapshot<code>" to
formatsnapshot.html.in. The closing tag is missing '/' which causes
the documentation to misrender.

Python code generator "generate_source" section that handles
code generation to "free" inherited objects needs to generate
DISPATCH_FREE calls for all extended_by objects.

For s390 we don't want to have a default USB device generated even
if QEMU is silently tolerating -usb on the command line. This may change
in the future.
Another reason to avoid the USB controller is that it implies a PCI
bus which might cause a regression at some later point in time.
The following change will set the USB controller model to 'none'
unless a model or address has been specified, which can be the case
if a legacy definition is loaded or the XML writer knows what
she/he's doing.
Requiring the user to explicitly disable USB on systems not supporting
it seems cumbersome.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

Add a line saying that no USB controllers are generated by default
on s390.

Commit eca3fdf7 inadvertantly caused a failure to start for any domain
with the following in its config:

    <graphics type='spice' autoport='yes'/>

The problem is that when tlsPort == 0 and defaultMode == "any" (which
is the default for defaultMode), this would be flagged in the code as
"needTLSPort", and if there was then no spice tls config, the new
error+fail would happen.

This patch checks for the case of defaultMode == "any", and in that
case simply doesn't allocate a TLS port (since that's probably not
what the user wanted, and it would have failed later anyway.). It does
leave the error in place for cases when the user specifically asked to
use tls in one way or another, though.

On cygwin, compilation failed because SIOCSIFHWADDR is undefined.

* src/util/virnetdev.c (virNetDevSetMAC): Cygwin can query but not
set mac address.
Signed-off-by: NEric Blake <eblake@redhat.com>

As a result of commit id '19c345f2', 'make -C tests valgrind' has the
following for qemuxml2argvtest:

==22482== 197 (80 direct, 117 indirect) bytes in 1 blocks are definitely lost in loss record 101 of 120
==22482==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==22482==    by 0x4C6F301: virAlloc (viralloc.c:124)
==22482==    by 0x4C840FC: virSaveLastError (virerror.c:308)
==22482==    by 0x431882: qemuBuildCommandLine (qemu_command.c:8204)
==22482==    by 0x41E8F0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:155)
==22482==    by 0x41FE9F: virtTestRun (testutils.c:157)
==22482==    by 0x419DEB: mymain (qemuxml2argvtest.c:654)
==22482==    by 0x4204DA: virtTestMain (testutils.c:719)
==22482==    by 0x39D0821A04: (below main) (libc-start.c:225)
==22482==

Return 3 when the service is stopped, whether there
are saved guests or not, to conform with the LSB standards:

http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

FreeBSD (and maybe other BSDs) have different member
names in struct ifreq when compared to Linux, such as:

 - uses ifr_data instead of ifr_newname for setting
   interface names
 - uses ifr_index instead of ifr_ifindex for interface
   index

Also, add a check for SIOCGIFHWADDR for virNetDevValidateConfig().

Use AF_LOCAL if AF_PACKET is not available.
Signed-off-by: NEric Blake <eblake@redhat.com>

If virPCIDeviceGetVFIOGroupDev() failed,
virSecurity*(Set|Restore)HostdevLabel() would fail to free a
virPCIDevice that had been allocated.

These leaks were all introduced (by me) very recently, in commit
f0bd70a9.

libxlBuildDomainConfig() was disposing the libxl_domain_config object
on error, only to have it disposed again by libxlBuildDomainConfig()'s
caller, which resulted in a segfault.  Leave disposing of the config
object to it's owner.

We already support ESX 5.1, but virtualHW version used by such
hypervisor [1] wasn't taken into account.

[1] http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1003746

These fixes solve a compilation failure on FreeBSD:

util/virnetdevtap.c: In function 'virNetDevTapGetName':
util/virnetdevtap.c:56: warning: unused parameter 'tapfd' [-Wunused-parameter]
util/virnetdevtap.c:56: warning: unused parameter 'ifname' [-Wunused-parameter]

* src/util/virnetdevtap.c (virNetDevTapGetName): Add attributes
when TUNGETIFF is not present.
Signed-off-by: NEric Blake <eblake@redhat.com>

Mention file/volume contents instead of just 'file'/'volume'.

Also change Download->download in vol-download help,
to be consistent with other volume commands.

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

qemuBuildMemballoonDevStr returns NULL if memballoon doesn't have
the right address type, but it doesn't report an error, leading to:
error: An error occurred, but the cause is unknown

Report a helpful error message instead, e.g.:
error: XML error: memballoon unsupported with address type 'usb'

This adds addresses to domxml-to-native output and chooses
the correct virtio devices for ccw and s390 machines.

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

For long options, print:
* the option as specified by the user if it's unknown
* the canonical long option if its argument is not
  a number (and should be)

And for missing arguments, print both the short and
the long option name.
(Doing only one of those would require either parsing
argv ourselves or let getopt print the errors, since
we can't tell long and short options apart by optopt
or longindex)

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

Unsupported long option:

$ virsh --pm
Before:
error: unsupported option '-
After:
error: unsupported option '--pm'. See --help.

Missing parameter:

$ virsh --deb
Before:
error: option '-d' requires an argument
After:
error: option '-d'/'--debug' requires an argument

$ virsh -rd
Before:
error: option '-d' requires an argument
After:
error: option '-d'/'--debug' requires an argument

Non-numeric parameter:

$ virsh --deb duck
Before:
error: option -d takes a numeric argument
After:
error: option --debug takes a numeric argument

When a user requests auto-allocation of the spice TLS port but spice TLS
is disabled in qemu.conf, we start the machine and let qemu fail instead
of erroring out sooner.

Add an error message so that this doesn't happen.

On the off-chance that creation of persistent configuration file would
fail when defining a network that is already started as transient, the
code would remove the transient data structure and thus the network.

This patch changes the code so that in such case, the network is again
marked as transient and left behind.

The USB-specific cgroup setup had been inserted inline in
qemuDomainAttachHostUsbDevice and qemuSetupCgroup, but now there is a
common cgroup setup function called for all hostdevs, so it makes sens
to put the usb-specific setup there and just rely on that function
being called.

The one thing I'm uncertain of here (and a reason for not pushing
until after release) is that previously hostdev->missing was checked
only when starting a domain (and cgroup setup for the device skipped
if missing was true), but with this consolidation, it is now checked
in the case of hotplug as well. I don't know if this will have any
practical effect (does it make sense to hotplug a "missing" usb
device?)

PCIO device assignment using VFIO requires read/write access by the
qemu process to /dev/vfio/vfio, and /dev/vfio/nn, where "nn" is the
VFIO group number that the assigned device belongs to (and can be
found with the function virPCIDeviceGetVFIOGroupDev)

/dev/vfio/vfio can be accessible to any guest without danger
(according to vfio developers), so it is added to the static ACL.

The group device must be dynamically added to the cgroup ACL for each
vfio hostdev in two places:

1) for any devices in the persistent config when the domain is started
   (done during qemuSetupCgroup())

2) at device attach time for any hotplug devices (done in
   qemuDomainAttachHostDevice)

The group device must be removed from the ACL when a device it
"hot-unplugged" (in qemuDomainDetachHostDevice())

Note that USB devices are already doing their own cgroup setup and
teardown in the hostdev-usb specific function. I chose to make the new
functions generic and call them in a common location though. We can
then move the USB-specific code (which is duplicated in two locations)
to this single location. I'll be posting a followup patch to do that.

My commit 024e9af3 broke this.

I removed it in 5c3d5b22 by accident.