Add a new attribute 'rendernode' to <gl> spice element.

Give it to QEMU if qemu supports it (queued for 2.9).
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new 'drm' capability for Direct Rendering Manager (DRM) devices,
providing device type information.

Teach the udev backend to populate those devices.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This should have been added with c4a4603d (or 0bdefd9b).
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

Add new <devnode> top-level <device> element, that list the associated
/dev files. Distinguish the main /dev name from symlinks with a 'type'
attribute of value 'dev' or 'symlink'.

Update a test to check XML schema, and actually add it to the test list
since it was missing.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

This is a cosmetic change, shouldn't change XML parsing, and doesn't
break any test.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

When the 'parent' was added to the virNodeDevicePtr structure
by commit id 'e8a4ea75' the 'parent' field was not properly filled
in when a virGetNodeDevice call was made within driver/config code.
Only the device name was ever filled in. Fetching the parent required
a second trip via virNodeDeviceGetParent into the node device lookup
code was required in order to retrieve the specific parent field (and
still the parent field was never filled in although it was free'd).

Since we have the data when we initially call virGetNodeDevice from
within driver/node_config code - let's just fill in the parent field
as well for anyone that wants it without requiring another trip into
the node_device lookup just to get the parent.

This will allow API's such as virConnectListAllNodeDevices,
virNodeDeviceLookupByName, and virNodeDeviceLookupSCSIHostByWWN
to retrieve both name and parent in the returned virNodeDevicePtr.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the range check introduced by commit 2650d5e1 into
virDomainUSBAddressFindPort. That way both virDomainUSBAddressRelease
and virDomainUSBAddressSetAddHub can benefit from it.
Reported-by: NMichal Privoznik <mprivozn@redhat.com>

If virDomainChrSourceDefNew(xmlopt) fails, it will lead to free()ing
the uninitialized pointer bus. The fix for this is to initialize bus
with NULL.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>

This part introduces new xml elements for file based
memorybacking support and their parsing.
(It allows vhost-user to be used without hugepages.)

New xml elements:
<memoryBacking>
  <source type="file|anonymous"/>
  <access mode="shared|private"/>
  <allocation mode="immediate|ondemand"/>
</memoryBacking>

Rename to avoid duplicate code. Because virDomainMemoryAccess will be
used in memorybacking for setting default behaviour.

NOTE: The enum cannot be moved to qemu/domain_conf because of headers
dependency

Example:

  <network>
     ...
     <mtu size='9000'/>
     ...

If mtu is unset, it's assumed that we want the default for whatever is
the underlying transport (usually this is 1500).

This setting isn't yet wired in, so it will have no effect.

This partially resolves: https://bugzilla.redhat.com/1224348

That function sets disk->blkdeviotune sensibly.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

For reusing in qemu_domain_address.c.

The issue is that if this graphics definition is provided:

  <graphics type='vnc' port='0'/>

it's parsed as:

  <graphics type='vnc' autoport='no'>
    <listen type='address'/>
  </graphics>

but if the resulting XML is parsed again the output is:

  <graphics type='vnc' port='-1' autoport='yes'>
    <listen type='address'/>
  </graphics>

and this should not happen.  The XML have to always remain the same
after it was already parsed by libvirt.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1383039Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Added general definitions for vstorage pool backend including
the build options to add --with-storage-vstorage checking.
In order to use vstorage as a backend for a storage pool
vstorage tools (vstorage and vstorage-mount) need to be installed.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

So far we allow to set MTU for libvirt networks. However, not all
domain interfaces have to be plugged into a libvirt network and
even if they are, they might want to have a different MTU (e.g.
for testing purposes).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We use @ret to hold the actual return value of the function we
are currently in. To hold a return value of a function called we
use different variables: @rv, @rc, etc. Honour this naming
scheme in virDomainNetDefParseXML too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

==24748== 12 bytes in 2 blocks are definitely lost in loss record 25 of 84
==24748==    at 0x4C2BF80: malloc (vg_replace_malloc.c:296)
==24748==    by 0x1A1E1E78: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==24748==    by 0x18D0495F: virXMLPropString (virxml.c:506)
==24748==    by 0x18D1FB3E: virDomainHostdevSubsysSCSIVHostDefParseXML (domain_conf.c:6280)
==24748==    by 0x18D20350: virDomainHostdevDefParseXMLSubsys (domain_conf.c:6450)
==24748==    by 0x18D34E7D: virDomainHostdevDefParseXML (domain_conf.c:13218)
==24748==    by 0x18D42598: virDomainDefParseXML (domain_conf.c:17745)
==24748==    by 0x18D440A9: virDomainDefParseNode (domain_conf.c:18236)
==24748==    by 0x18D43EFA: virDomainDefParse (domain_conf.c:18180)
==24748==    by 0x18D43FA0: virDomainDefParseFile (domain_conf.c:18206)
==24748==    by 0x44EDA1: testCompareDomXML2XMLFiles (testutils.c:1140)
==24748==    by 0x4365F8: testXML2XMLActive (qemuxml2xmltest.c:59)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Surprisingly there was a virDomainPCIAddressReleaseAddr() function
already, but it was completely unused. Since we don't reserve entire
slots at once any more, there is no need to release entire slots
either, so we just replace the single call to
virDomainPCIAddressReleaseSlot() with a call to
virDomainPCIAddressReleaseAddr() and remove the now unused function.

The keen observer may be concerned that ...Addr() doesn't call
virDomainPCIAddressValidate(), as ...Slot() did. But really the
validation was pointless anyway - if the device hadn't been suitable
to be connected at that address, it would have failed validation
before every being reserved in the first place, so by definition it
will pass validation when it is being unplugged. (And anyway, even if
something "bad" happened and we managed to have a device incorrectly
at the given address, we would still want to be able to free it up for
use by a device that *did* validate properly).

This function doesn't actually reserve an entire slot any more, it
reserves a single PCI address, so this name is more appropriate.

This is in preparation for renaming virDomainPCIAddressReserveSlot()
to virDomainPCIAddressReserveAddr(), which is a better description of
what it does.

It is now only used in domain_addr.c.

Since we don't actually reserve an entire slot at a time anymore, the
name of this function is just confusing, and it's almost identical in
operation to virDomainPCIAddressReserveNextAddr() anyway, so remove
the *Slot() function and replace calls to it with calls to *Addr(...,
-1).

With the advent of VIR_PCI_CONNECT_AGGREGATE_SLOT, the new name is
more appropriate, since the address returned may be another address
on the same slot as last time, not necessarily a new slot.

fromConfig should be true if the caller wants
virDomainPCIAddressValidate() to loosen restrictions on its
interpretation of the pciConnectFlags. In particular, either
PCI_DEVICE or PCIE_DEVICE will be counted as equivalent to both, and
HOTPLUG will be ignored. In a few cases where libvirt was manually
overriding automatic address assignment, it was setting fromConfig to
false when validating the hardcoded manual override. This patch
changes those to fromConfig=true as a preemptive strike against any
future bugs that might otherwise surface.

Although setting virDomainPCIAddressReserveAddr()'s fromConfig=true is
correct when a PCI addres is coming from a domain's config, the *true*
purpose of the fromConfig argument is to lower restrictions on what
kind of device can plug into what kind of controller - if fromConfig
is true, then a PCIE_DEVICE can plug into a slot that is marked as
only compatible with PCI_DEVICE (and vice versa), and the HOTPLUG flag
is ignored.

For a long time there have been several calls to
virDomainPCIAddressReserveAddr() that have fromConfig incorrectly set
to false - it's correct that the addresses aren't coming from user
config, but they are coming from hardcoded exceptions in libvirt that
should, if anything, pay *even less* attention to following the
pciConnectFlags (under the assumption that the libvirt programmer knew
what they were doing).

See commit b87703cf for an example of an actual bug caused by the
incorrect setting of the "fromConfig" argument to
virDomainPCIAddressReserveAddr(). Although they haven't resulted in
any reported bugs, this patch corrects all the other incorrect
settings of fromConfig in calls to virDomainPCIAddressReserveAddr().

Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so
that they will be assigned to all the functions on a slot.

Some qemu test case outputs had to be adjusted due to the
pcie-root-ports now being put on multiple functions.

If a PCI device has VIR_PCI_CONNECT_AGGREGATE_SLOT set in its
pciConnectFlags, then during address assignment we allow multiple
instances of this type of device to be auto-assigned to multiple
functions on the same device. A slot is used for aggregating multiple
devices only if the first device assigned to that slot had
VIR_PCI_CONNECT_AGGREGATE_SLOT set. but any device types that have
AGGREGATE_SLOT set might be mix/matched on the same slot.

(NB: libvirt should never set the AGGREGATE_SLOT flag for a device
type that might need to be hotplugged. Currently it is only planned
for pcie-root-port and possibly other PCI controller types, and none
of those are hotpluggable anyway)

There aren't yet any devices that use this flag. That will be in a
later patch.

This utility function iterates through all devices looking for any
with a PCI address that has function != 0 (which implies that multiple
functions are in use on that slot), then uses an inner iterator to
find the device that's on function 0 of that same slot and sets the
"multi" in its virDomainDeviceInfo (as long as it hasn't already been
set explicitly by someone who presumably has better information than
we do).

It isn't yet called from anywhere, so will have no functional effect.

There is a very slight time advantage to beginning the search for the
next unused PCI address at the slot *after* the previous find (which
is now used), but if we do that, we will miss allocating the other
functions of the same slot (when we implement a
VIR_PCI_CONNECT_AGGREGATE_SLOT flag to support that).

virDomainPCIAddressGetNextSlot() starts searching from the last
allocated address and goes to the end of all the buses, then goes back
to the first bus and searches from there up to the starting point (in
case any address has been freed since the last time an address was
allocated. The loops for these two are almost, but not exactly, the
same, so they have remained as separate loops with the same code
inside the loop. To lessen maintenance headaches, the identical code
has been moved out into the function
virDomainPCIAddressFindUnusedFunctionOnBus(), which is called in place
of the loop contents.

setting reserveEntireSlot really accomplishes nothing - instead of
going to the trouble of computing the value for reserveEntireSlot and
then possibly setting *all* functions of the slot as in-use, we can
just set the in-use bit only for the specific function being used by a
device.  Later we will know from the context (the PCI connect flags,
and whether we are reserving a specific address or asking for "the
next available") whether or not it is okay to allocate other functions
on the same slot.

Although it's not used yet, we allow specifying "-1" for the function
number when looking for the "next available slot" - this is going to
end up meaning "return the lowest available function in the slot, but
since we currently only provide a function from an otherwise unused
slot, "-1" ends up meaning "0".

When keeping track of which functions of which slots are allocated, we
will need to have more information than just the current bitmap with a
bit for each function that is currently stored for each slot in a
virDomainPCIAddressBus. To prepare for adding more per-slot info, this
patch changes "uint8_t slots" into "virDomainPCIAddressSlot slot", which
currently has a single member named "functions" that serves the same
purpose previously served directly by "slots".

Emit an event whenever a secret value changes
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The public virSecret object has a single "usage_id" field
but the virSecretDef object has a different 'char *' field
for each usage type, but the code all assumes every usage
type has a corresponding single string. Get rid of the
pointless union in virSecretDef and just use "usage_id"
everywhere. This doesn't impact public XML format, only
the internal handling.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add helper APIs / objects for managing secret events
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When changing the metadata via virDomainSetMetadata, we now
emit an event to notify the app of changes. This is useful
when co-ordinating different applications read/write of
custom metadata.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add new fields to the fchost structure to allow creation of a vHBA via
the storage pool when a parent_wwnn/parent_wwpn or parent_fabric_wwn is
supplied in the storage pool XML.

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

When creating a vHBA, the process is to feed XML to nodeDeviceCreateXML
that lists the <parent> scsi_hostX to use to create the vHBA. However,
between reboots, it's possible that the <parent> changes its scsi_hostX
to scsi_hostY and saved XML to perform the creation will either fail or
create a vHBA using the wrong parent.

So add the ability to provide "wwnn" and "wwpn" or "fabric_wwn" to
the <parent> instead of a name of the scsi_hostN that is the parent.
The allowed XML will thus be:

  <parent>scsi_host3</parent>  (current)

or

  <parent wwnn='$WWNN' wwpn='$WWPN'/>

or

  <parent fabric_wwn='$WWNN'/>

Using the wwnn/wwpn or fabric_wwn ensures the same 'scsi_hostN' is
selected between hardware reconfigs or host reboots. The fabric_wwn
Using the wwnn/wwpn pair will provide the most specific search option,
while fabric_wwn will at least ensure usage of the same SAN, but maybe
not the same scsi_hostN.

This patch will add the new fields to the nodedev.rng for input purposes
only since the input XML is essentially thrown away, no need to Format
the values since they'd already be printed as part of the scsi_host
data block.

New API virNodeDeviceGetParentHostByWWNs will take the parent "wwnn" and
"wwpn" in order to search the list of devices for matching capability
data fields wwnn and wwpn.

New API virNodeDeviceGetParentHostByFabricWWN will take the parent "fabric_wwn"
in order to search the list of devices for matching capability data field
fabric_wwn.

If a <parent> is not supplied in the XML used to create a non-persistent
vHBA, then instead of failing, let's try to find a "vports" capable node
device and use that.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>