Commit 5ed235c6 added unnecessary redifinition of
virDomainCapsDeviceHostdev in conf/domain_capabilities.h. This breaks
build with clang 3.4:

In file included from conf/domain_capabilities.c:25:
conf/domain_capabilities.h:88:44: error: redefinition of typedef
'virDomainCapsDeviceHostdev' is a C11 feature
[-Werror,-Wtypedef-redefinition]
typedef struct _virDomainCapsDeviceHostdev virDomainCapsDeviceHostdev;
                                           ^
conf/domain_capabilities.h:86:44: note: previous definition is here
typedef struct _virDomainCapsDeviceHostdev virDomainCapsDeviceHostdev;

So drop one of those.

If the call to virXPathNodeSet to set naddresses fails, Coverity notes
that the subsequent VIR_ALLOC_N cannot have a negative value (well it
probably wouldn't be negative per se).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Requires adding the plumbing for <device><video>
The value is <enum name='modelType'> to match the associated domain
XML of <video><model type='XXX'/>

Wire it up for qemu too

Requires adding the plumbing for <device><graphics>
Wire it up for qemu too

Commin 36785c7e refactored the code for input devices but introduced a
bug where we removed all keyboard from migratable XML.  We have to
remove only implicit keyboards like PS2 or XEN.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add the ability to add an 'iothread' to the controller which will be how
virtio-scsi-pci and virtio-scsi-ccw iothreads have been implemented in qemu.

Describe the new functionality and add tests to parse/validate that the
new attribute can be added.

Move virDomainControllerModelTypeToString closer to it's counterpart
virDomainControllerModelTypeFromString.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This adds a ports= attribute to usb controller XML, like

  <controller type='usb' model='nec-xhci' ports='8'/>

This maps to:

  qemu -device nec-usb-xhci,p2=8,p3=8

Meaning, 8 ports that support both usb2 and usb3 devices. Gerd
suggested to just expose them as one knob.

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

Rather than reimplement it. This will be needed in upcoming patches

If a panic device is being defined without a model in a domain
the default value is always overwritten with model ISA. An ISA
bus does not exist on S390 and therefore specifying a panic device
results in an unsupported configuration.
Since the S390 architecture inherently provides a crash detection
capability the panic device should be defined in the domain xml.

This patch adds an s390 panic device model and prevents setting a
device address on it.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>

libvirt-daemon-config-nwfilter will put a bunch of xml configs
into /etc/libvirt/nwfilter. These configs don't hardcode a UUID
and depends on libvirt to generate one. However the generated UUID
is never saved to disk, unless the user manually calls Define.

This makes daemon reload quite noisy with many errors like:

error : virNWFilterObjAssignDef:3101 : operation failed: filter 'allow-incoming-ipv4' already exists with uuid 50def3b5-48d6-46a3-b005-cc22df4e5c5c

Because a new UUID is generated every time the config is read from
disk, so libvirt constantly thinks it's finding a new nwfilter.

Detect if we generated a UUID when the config file is loaded; if so,
resave the new contents to disk to ensure the UUID is persisteny.

This is similar to what was done in commit a47ae7c0 with virtual
networks and generated MAC addresses

This matches the pattern used for network object APIs, and we want
configDir in LoadConfig for upcoming patches

In virNWFilterObjLoad we can still fail after virNWFilterObjAssignDef,
but we don't unlock and free the created virNWFilterObjPtr in the
cleanup path.

The bit we are trying to do after AssignDef is just STRDUP in the
configFile path. However caching the configFile in the NWFilterObj
is largely redundant and doesn't follow the same pattern we use
for domain and network objects.

So just remove all the configFile caching which fixes the latent
bug as a side effect.

We historically format runtime seclabel selinux/apparmor values,
however we skip formatting runtime DAC values. This was added in

commit 990e46c4
Author: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
Date:   Fri Aug 31 13:40:41 2012 +0200

    conf: Avoid formatting auto-generated DAC labels

to maintain migration compatibility with libvirt < 0.10.0.

However the formatting was skipped unconditionally. Instead only
skip formatting in the VIR_DOMAIN_DEF_FORMAT_MIGRATABLE case.

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

Trying to define a pool name containing an embedded '/'
will immediately fail when trying to write the XML to disk.
This patch explicitly rejects names containing a '/'

Besides our stateful driver, there are two other storage impls:
esx and phyp. esx doesn't support pool creation, so this should
doesn't apply.

phyp does support pool creation, and the name is passed to the
'mksp' tool, which google doesn't reveal whether it accepts '/'
or not. IMO the likeliness of this impacting any users is near zero

Trying to define a network name containing an embedded '/'
will immediately fail when trying to write the XML to disk.
This patch explicitly rejects names containing a '/'

Besides the network bridge driver, the only other network
implementation is a very thin one for virtualbox, which seems to
use the network name as a host interface name, which won't
accept '/' anyways, so I think this is fine to do unconitionally.

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

Trying to define a domain name containing an embedded '/'
will immediately fail when trying to write the XML to disk for
our stateful drivers. This patch explicitly rejects names
containing a '/', and provides an xmlopt feature for drivers
to avoid this validation check, which is enabled in every
non-stateful driver that already has xmlopt handling wired up.

(Technically this could reject a previously accepted vmname like
 '/foo', however at least for the qemu driver that falls over
 later when starting qemu)

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

We were lacking tests that are checking for the completeness of our
nodedev XMLs and also whether we output properly formatted ones.  This
patch adds parsing for the capability elements inside the <capability
type='pci'> element.  Also bunch of tests are added to show everything
works properly.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

All sub-PCI capabilities should be next to each other for clarity.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We had both and the only difference was that the latter also included
information about multifunction setting.  The problem with that was that
we couldn't use functions made for only one of the structs (e.g.
parsing).  To consolidate those two structs, use the one in virpci.h,
include that in domain_conf.h and add the multifunction member in it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Modeled after the qemuDomainDiskPrivatePtr logic, create a privateData
pointer in the _virDomainHostdevDef to allow storage of private data
for a hypervisor in order to at least temporarily store auth/secrets
data for usage during qemuBuildCommandLine.

NB: Since the qemu_parse_command (qemuParseCommandLine) code is not
expecting to restore the auth/secret data, there's no need to add
code to handle this new structure there.

Updated copyrights for modules touched. Some didn't have updates in a
couple years even though changes have been made.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This reverts commit 690969af, which
added the domain config parts to support a "peer" attribute in domain
interface <ip> elements.

It's being removed temporarily for the release of libvirt 1.3.4
because the feature doesn't work, and there are concerns that it may
need to be modified in an externally visible manner which could create
backward compatibility problems.

Similarly to what commit 71408079 did with some internal paths,
clear vnc socket paths that were generated by us.  Having such path in
the definition can cause trouble when restoring the domain.  The path is
generated to the per-domain directory that contains the domain ID.
However, that ID will be different upon restoration, so qemu won't be
able to create that socket because the directory will not be prepared.

To be able to migrate to older libvirt, skip formatting the socket path
in migratable XML if it was autogenerated.  And mark it as autogenerated
if it already exists and we're parsing live XML.

Best viewed with '-C'.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1326270Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Add virDomainObjGetShortName() and use it.  For now that's used in one
place, but we should expose it so that future patches can use it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Currently we only allow /dev/random and /dev/hwrng as host input
for <rng><backend model='random'/> device. This was added after
various upstream discussions in commit 4932ef45

However this restriction has generated quite a few complaints over
the years, so a new discussion was initiated:

http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html

Several people suggested removing the restriction, and nobody really
spoke up to defend it. So this patch drops the path restriction
entirely

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

Change 'ephemeral' to 'isephemeral' and 'private' to 'isprivate' since
both are bools.

Introduce the final accessor's to _virSecretObject data and move the
structure from virsecretobj.h to virsecretobj.c

The virSecretObjSetValue logic will handle setting both the secret
value and the value_size. Some slight adjustments to the error path
over what was in secretSetValue were made.

Additionally, a slight logic change in secretGetValue where we'll
check for the internalFlags and error out before checking for
and erroring out for a NULL secret->value. That way, it won't be
obvious to anyone that the secret value wasn't set rather they'll
just know they cannot get the secret value since it's private.

Introduce fetch and set accessor to the secretObj->def field for usage
by the driver to avoid the driver needing to know the format of virSecretObj

Move and rename the secretRewriteFile, secretSaveDef, and secretSaveValue
from secret_driver to virsecretobj

Need to make some slight adjustments since the secretSave* functions
called secretEnsureDirectory, but otherwise mostly just a move of code.

Move and rename secretDeleteSaved from secret_driver into virsecretobj and
split it up into two parts since there is error path code that looks to
just delete the secret data file

Move to secret_conf.c and rename to virSecretLoadAllConfigs. Also includes
moving/renaming the supporting virSecretLoad, virSecretLoadValue, and
virSecretLoadValidateUUID.

This patch replaces most of the guts of secret_driver.c with recently
added secret_conf.c APIs in order manage secret lists and objects
using the hashed virSecretObjList* lookup API's.

Add function to return counted listed of uuids to from the hashed secrets
object list. This will replace the guts of secretConnectListSecrets.

Add function to return a "match" filtered list of secret objects. This
function replaces the guts of secretConnectListAllSecrets.

Need to also move and make global virSecretUsageIDForDef since it'll
be used by both secret_driver.c and secret_conf.c

Add function to count the hashed secret obj list with filters. This
will replace the guts of secret_driver's secretConnectNumOfSecrets.

Add the functions to add/remove elements from the hashed secret obj list.
These will replace secret_driver functions secretAssignDef and secretObjRemove.

The virSecretObjListAddLocked will perform the necessary lookups and
decide whether to replace an existing hash entry or create a new one.
This includes setting up the configPath and base64Path as well as being
able to support the caller's need to restore from a previous definition
in case something goes wrong in the caller.

Move the driver specific secretUsageIDForDef into secret_conf.c. It could
be more of a general purpose API.

New API's including unlocked and Locked versions in order to be able
to use in either manner.

Support for searching hash object lists instead of linked lists will
replace existing secret_driver functions secretFindByUUID and
secretFindByUsage