This bug was revealed by the crash described in

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

The vlan info pointer sent to virNetDevOpenvswitchAddPort should never
be non-NULL unless there is at least one tag. The factthat such a vlan
info pointer was receveid pointed out that a caller was passing the
wrong pointer. Instead of sending &net->vlan, the result of
virDomainNetGetActualVlan(net) should be sent - that function will
look for vlan info in net->data.network.actual->vlan, and in cany case
return NULL instead of a pointer if the vlan info it finds has no
tags.

Aside from causing the crash, sending a hardcoded &net->vlan has the
effect of ignoring vlan info from a <network> or <portgroup> config.

As pointed by Eric Blake

Fixup buffer usage when handling VLANs. Also fix the logic
used to determine if the virNetDevVlanPtr is valid or not.
Fixes crashes in the latest code when using Open vSwitch
virtualports.
Signed-off-by: NKyle Mestery <kmestery@cisco.com>

As the next boot doesn't have to worry about the previous numa
params setting (there is no).

If no 'security_driver' config option was set, then the code
just loaded the 'dac' security driver. This is a regression
on previous behaviour, where we would probe for a possible
security driver. ie default to SELinux if available.

This changes things so that it 'security_driver' is not set,
we once again do probing. For simplicity we also always
create the stack driver, even if there is only one driver
active.

The desired semantics are:

 - security_driver not set
     -> probe for selinux/apparmour/nop
     -> auto-add DAC driver
 - security_driver set to a string
     -> add that one driver
     -> auto-add DAC driver
 - security_driver set to a list
     -> add all drivers in list
     -> auto-add DAC driver

It is not allowed, or possible to specify 'dac' in the
security_driver config param, since that is always
enabled.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The security driver loading code in qemu has a flaw that causes it to
register the DAC security driver twice. This causes problems (machines
unable to start) as the two DAC drivers clash together.

This patch refactors the code to allow loading the DAC driver even if
its specified in configuration (it can't be registered as a common
security driver), and does not add the driver twice.

This reverts commit 9f9b7b85.

The DAC security driver needs special handling and extra parameters and
can't just be added to regular security drivers.

If cgroups are enabled in general but cpu cgroup is disabled in
qemu.conf or not mounted at all, libvirt would refuse to start any
domain even though scheduler parameters are not set in domain XML.

This patch makes cpu cgroup mandatory only for domains that actually
want to use it.

* src/security/security_dac.c: remove useless dead code.
Signed-off-by: NAlex Jia <ajia@redhat.com>

* configure.ac docs/news.html.in libvirt.spec.in: updates for the release
* po/*.po*: update localizations for zh_CN, uk, ja, pt_BR, as, sp, mr, zh_TW

To silence error if DBus support is not compiled in.

Fedora uses gawk as awk so there's no change and in behavior while
Debian/Ubuntu use mawk by default.

This was reported by Luca Capello in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636712

* src/util/virnetdevopenvswitch.c (virNetDevOpenvswitchAddPort): avoid libvirtd
crash due to derefing a NULL virtVlan->tag.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=852383Signed-off-by: NAlex Jia <ajia@redhat.com>

To keep the internal data structure consistent.

The commits d5756794 and
080bf330 made use directly of
macro defined in recent linux netlink version. Make those
part conditional on the definition

* daemon/libvirtd.c: do not use NETLINK_ROUTE and NETLINK_KOBJECT_UEVENT
  without some check first

As in the previous commit, images are also chowned to uninitialised
uid and gid if the label is not present.

When starting a machine the DAC security driver tries to set the UID and
GID of the newly spawned process. This worked as desired if the desired
label was set. When the label was missing a logical bug in
virSecurityDACGenLabel() caused that uninitialised values were used as
uid and gid for the new process.

With this patch, default values (from qemu driver configuration)
are used if the label is not found.

When no DAC "label" was requested for a domain the DAC manager tried to
strdup a NULL string causing a segfault.

getpwuid_r returns success but sets the return structure to NULL when it
fails to deliver data about the requested uid. In our helper code this
created following strange error messages:

" ... cannot getpwuid_r(1234): Success"

This patch creates a more helpful message:
" ... getpwuid_r failed to retrieve data for uid '1234'"

* src/conf/domain_conf.c: Use STREQ_NULLABLE instead of STREQ,
as def->seclables[i]->model could be NULL.

Previous commit 0b4b53bb defined 'inline' to prevent broken build on
systems with libnl1 headers. However, it broke build on systems with
libnl3 headers. Therefore we must make that fix conditional.

There was a request for clarifying this part of the
documentation. This also fixes a case used with CPU.

Ubuntu 10.04 shipped with out-of-the-box libnl1 headers, which
assumed the old gcc semantics of 'extern inline' as a C89 extension:
the function will _always_ be inline if it is used, and that
it may be declared extern inline in headers without a definition,
as long as the definition occurs before any use.  But when C99
added 'extern inline' as a mandatory feature of the language, with
slightly different semantics than gcc (the function MUST have
external linkage, and the inline definition MUST be present
alongside any declaration, where the compiler can then choose
which of the two versions to use), this rendered the use of
'inline' in libnl's header obsolete.  Most distros already solved
this by removing 'inline' (the resulting 'extern' is correct,
regardless of gcc semantics), and libnl-3 does not have the
problem (where it has switched to 'static inline' instead, again
with the definition present, and again, our hack will result in
plain 'static' with no ill effects).  But for the case of building
out of the box, we hack around the broken Ubuntu header.

* src/util/virnetlink.h: Work around libnl issue.

With current flow in qemudDomainDefine we might lose data
when updating an existing domain. We parse given XML and
overwrite the configuration.  Then we try to save the new
config. However, this step may fail and we don't perform any
roll back.  In fact, we remove the domain from the list of
domains held up by qemu driver. This is okay as long as the
domain was brand new one.

Currently, if a syscall in qemu_agent.c fails we report an internal
error even though we should be reporting a system error.

Currently, when guest agent is configured but not responsive
(e.g. due to appropriate service not running in the guest)
we return VIR_ERR_INTERNAL_ERROR. Both are wrong. Therefore
we need to introduce new error code to reflect this case.

When checking for seclabels without security models, def->nseclabels is
already set to n. In the case of an error def->seclabels is freed but
nseclabels is left untouched. This leads to a segmentation fault when
def is freed in virDomainDefParseXML.

With the latest patches libvirt supports qemu agent monitor
passthrough. However, function in qemu driver is called
qemuDrvDomainAgentCommand. s/Drv// as used in all other names.

The client-sock could have been set to NULL by eventloop thread
after async event fired.

In my quest for reusing variables I failed to edit one variable when
fixing details between two patch versions. That results in a failure
to start qemu with autoport and spice tls, because qemu is trying to
bind two sockets to the same port.

Commit 4b03d591 changed the pinning
behavior in a way that makes some machines non-startable.

The comment mentioning that we cannot control each vcpu when there is
not VCPU<-> PID mapping available is true, however, this isn't
necessarily an error, because this can be caused by old QEMU without
support for "query-cpus" command as well as a software emulated
machines that don't create more than one process.

Although virsh command raises a correct error information, the command status
returns 0(true), this patch is used for fixing this issue.
Signed-off-by: NAlex Jia <ajia@redhat.com>

Everything is ready in both netcf and libvirt to switch over to libnl3
in future releases of both Fedora and RHEL. This needs to be done more
or less simultaneously in both packages, though, because you can't mix
libnl1.1 and libnl3 in the same process (e.g. libvirtd using
libnl-3.so and libnetcf.so, while libnetcf.so uses libnl.so)

This patch does two things when fedora >= 18 || rhel >= 7):

  1) requires libnl3-devel
  2) requires netcf-devel-0.2.2 or greater

(the idea is that a similar patch is going into netcf's specfile, so
that when a build of netcf is done on F18 or later (or RHEL7 or later)
netcf will be guaranteed to be built with libnl3 rather than
libnl-1.1)

When libvirt_lxc is built, it uses the utility library and #includes
virnetdev.h, which #includes virnetlink.h, which includes
<netlink/msg.h>.

Normally, the netlink include directory would be just off
/usr/include, so that wouldn't create a problem, but on Fedora and
RHEL systems using libnl3, the libnl includes have been moved into
/usr/include/libnl3 (to allow concurrent installation of libnl-1.1).

All other binaries that need it have added $(LIBNL_CFLAGS) to their
CFLAGS, but not libvirt_lxc, so it fails to build on Fedora and RHEL
that have only libnl3-devel installed. This was previously unnoticed
because everyone was building with libnl headers in
/usr/include/netlink (even on systems with the headers in
/usr/include/libnl3/netlink, many people (like me) usually also have
the libnl1.1 headers in /usr/include/netlink).

This patch adds the necessary CFLAGS for libvirt_lxc.

Note that we don't need to add $(LIBNL_LIBS) to the LDADD for this
binary, because it never directly calls libnl functions, but only
calls them indirectly through the util library, which it's already
linking against.

The name 'virDomainDiskSnapshot' didn't fit in with our normal
conventions of using a prefix hinting that it is related to a
virDomainSnapshotPtr.  Also, a future patch will reuse the
enum for declaring where the VM memory is stored.

* src/conf/snapshot_conf.h (virDomainDiskSnapshot): Rename...
(virDomainSnapshotLocation): ...to this.
(_virDomainSnapshotDiskDef): Update clients.
* src/conf/domain_conf.h (_virDomainDiskDef): Likewise.
* src/libvirt_private.syms (domain_conf.h): Likewise.
* src/conf/domain_conf.c (virDomainDiskDefParseXML)
(virDomainDiskDefFormat): Likewise.
* src/conf/snapshot_conf.c: (virDomainSnapshotDiskDefParseXML)
(virDomainSnapshotAlignDisks, virDomainSnapshotDefFormat):
Likewise.
* src/qemu/qemu_driver.c (qemuDomainSnapshotDiskPrepare)
(qemuDomainSnapshotCreateSingleDiskActive)
(qemuDomainSnapshotCreateDiskActive, qemuDomainSnapshotCreateXML):
Likewise.

This has several benefits:
1. Future snapshot-related code has a definite place to go (and I
_will_ be adding some)
2. Snapshot errors now use the VIR_FROM_DOMAIN_SNAPSHOT error
classification, which has been underutilized (previously only in
libvirt.c)

* src/conf/domain_conf.h, domain_conf.c: Split...
* src/conf/snapshot_conf.h, snapshot_conf.c: ...into new files.
* src/Makefile.am (DOMAIN_CONF_SOURCES): Build new files.
* po/POTFILES.in: Mark new file for translation.
* src/vbox/vbox_tmpl.c: Update caller.
* src/esx/esx_driver.c: Likewise.
* src/qemu/qemu_command.c: Likewise.
* src/qemu/qemu_domain.h: Likewise.

We were failing to react to allocation failure when initializing
a snapshot object list.  Changing things to store a pointer
instead of a complete object adds one more possible point of
allocation failure, but at the same time, will make it easier to
react to failure now, as well as making it easier for a future
patch to split all virDomainSnapshotPtr handling into a separate
file, as I continue to add even more snapshot code.

Luckily, there was only one client outside of domain_conf.c that
was actually peeking inside the object, and a new wrapper function
was easy.

* src/conf/domain_conf.h (_virDomainObj): Use a pointer.
(virDomainSnapshotObjListInit): Rename.
(virDomainSnapshotObjListFree, virDomainSnapshotForEach): New
declarations.
(_virDomainSnapshotObjList): Move definitions...
* src/conf/domain_conf.c: ...here.
(virDomainSnapshotObjListInit, virDomainSnapshotObjListDeinit):
Rename...
(virDomainSnapshotObjListNew, virDomainSnapshotObjListFree): ...to
these.
(virDomainSnapshotForEach): New function.
(virDomainObjDispose, virDomainListPopulate): Adjust callers.
* src/qemu/qemu_domain.c (qemuDomainSnapshotDiscard)
(qemuDomainSnapshotDiscardAllMetadata): Likewise.
* src/qemu/qemu_migration.c (qemuMigrationIsAllowed): Likewise.
* src/qemu/qemu_driver.c (qemuDomainSnapshotLoad)
(qemuDomainUndefineFlags, qemuDomainSnapshotCreateXML)
(qemuDomainSnapshotListNames, qemuDomainSnapshotNum)
(qemuDomainListAllSnapshots)
(qemuDomainSnapshotListChildrenNames)
(qemuDomainSnapshotNumChildren)
(qemuDomainSnapshotListAllChildren)
(qemuDomainSnapshotLookupByName, qemuDomainSnapshotGetParent)
(qemuDomainSnapshotGetXMLDesc, qemuDomainSnapshotIsCurrent)
(qemuDomainSnapshotHasMetadata, qemuDomainRevertToSnapshot)
(qemuDomainSnapshotDelete): Likewise.
* src/libvirt_private.syms (domain_conf.h): Export new function.

When the XenStore tdb lives persistently and is not cleared between host
reboots, Xend (version 3.4 and 4.1) re-creates the domain information
located in XenStore below /vm/$UUID. (According to the xen-3.2-commit
hg265950e3df69 to fix a problem when locally migrating a domain to the
host itself.)

When doing so a version number is added to the UUID separated by one
dash, which confuses xenStoreDomainIntroduced(): It iterates over all
domains and tries to lookup all inactive domains using
xenStoreDomainGetUUID(), which fails if the running domain is renamed:
virUUIDParse() fails to parse the versioned UUID and the domain is
flagged as missing. When this happens the function delays .2s and
re-tries 20 times again, multiplied by the number of renamed VMs.
  14:48:38.878: 4285: debug : xenStoreDomainIntroduced:1354 : Some domains were missing, trying again

This adds a significant delay:
  # time virsh list >/dev/null
  real    0m6.529s
  # xenstore-list /vm
  00000000-0000-0000-0000-000000000000
  00000000-0000-0000-0000-000000000000-1
  00000000-0000-0000-0000-000000000000-2
  00000000-0000-0000-0000-000000000000-3
  00000000-0000-0000-0000-000000000000-4
  00000000-0000-0000-0000-000000000000-5
  7c06121e-90c3-93d4-0126-50481d485cca
  00000000-0000-0000-0000-000000000000-6
  00000000-0000-0000-0000-000000000000-7
  144ad19d-dfb4-2f80-8045-09196bb8784f
  00000000-0000-0000-0000-000000000000-8
  144ad19d-dfb4-2f80-8045-09196bb8784f-1
  00000000-0000-0000-0000-000000000000-9
  00000000-0000-0000-0000-000000000000-10
  00000000-0000-0000-0000-000000000000-11
  00000000-0000-0000-0000-000000000000-12
  00000000-0000-0000-0000-000000000000-13
  00000000-0000-0000-0000-000000000000-14
  144ad19d-dfb4-2f80-8045-09196bb8784f-2
  00000000-0000-0000-0000-000000000000-15
  144ad19d-dfb4-2f80-8045-09196bb8784f-3
  00000000-0000-0000-0000-000000000000-16

The patch adds truncation of the UUID as read from the XenStore path
before passing it to virUUIDParse().

The same issue is reported at
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666135>
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

Only parse model, if static labelling, or
a base label is set, or doing active XML.

Currently, if users set 'security_driver="dac"' in qemu.conf libvirtd
fails to initialize as DAC driver is not found because it is missing
in our security drivers array.