Somehow I put an example of a domain interface with a <vlan> element
into the network documentation.

This patch replaces that with an example of a network definition that
has a vlan element with trunk='yes', multiple tags, and even the new
nativeMode attribute. It also includes a <portgroup> that has a vlan
defined.

commit 0fc12bca added a new test called qemuhotplugtest which has
several data files in tests/qemuhotplugtestdata, but didn't add that
directory to EXTRA_DIST in the tests Makefile.am, so the make check
done during a make rpm was failing due to missing data files.

A loop in qemuPrepareHostdevPCIDevices() intended to cycle through all
the objects on the list pcidevs was doing "while (listcount > 0)", but
nothing in the body of the loop was reducing the size of the list - it
was instead removing items from a *different* list. It has now been
safely changed to a for() loop.

(This isn't as bad as it sounds - it's only a problem in case of an
OOM error.)

qemuGetActivePciHostDeviceList() had been creating a list that
contained pointers to objects that were also on the activePciHostdevs
list. In case of an OOM error, this newly created list would be
virObjectUnref'ed, which would cause everything on the list to be
freed. But all of those objects would still be on the
activePciHostdevs list, which could have very bad consequences if that
list was ever again accessed.

The solution used here is to populate the new list with *copies* of
the objects from the original list. It turns out that on return from
qemuGetActivePciHostDeviceList(), the caller would almost immediately
go through all the device objects and "steal" them (i.e. remove the
pointer from the list but not delete it) all from either one list or
the other; we now instead just *delete* (remove from the list and
free) each device from one list or the other, so in the end we have
the same state.

The "fix" I pushed a few commits ago would still leak a virPCIDevice
in case of an OOM error. Although it's inconsequential in practice,
this patch satisfies my OCD.

Make a copy of the device and add the copy to the
list. (virPCIDeviceListAdd() adds the original object to the list
instead).

If the device is bound to a stub driver different from what is saved
in the virPCIDevice's stubDriver attribute, update it.

The same strings were being re-created multiple times just to save
declaring a new variable. In the meantime, the use of the generic
variable names led to confusion when trying to follow the code. This
patch creates strings for:

 stubDriverName  (was called "driver" in original args)
 stubDriverPath  ("/sys/bus/pci/drivers/${stubDriverName}")
 driverLink      ("${device}/driver")
 oldDriverName   (the final component of path linked to by
                  "${device}/driver")
 oldDriverPath   ("/sys/bus/pci/drivers/${oldDriverName}")

then re-uses them as necessary.

This function has utility outside of virpci.c, so make it public.

Also the name didn't fit convention, so change it to
virPCIDeviceAddressParse.

I realized after the fact that it's probably better in the long run to
give this function a name that matches the name of the link used in
sysfs to hold the group (iommu_group).

I'm changing it now because I'm about to add several more functions
that deal with iommu groups.

The driver arg to virPCIDeviceDetach is no longer used (the name of the stub driver is now set in the virPCIDevice object, and virPCIDeviceDetach retrieves it from there). Remove it.

Commit 861d4056 added code (my personal change to "clean up" the
submitter's code, *not* the fault of the submitter) that dereferenced
virtVlan without first checking for NULL. This patch fixes that and,
as part of the fix, cleans up some unnecessary obtuseness.

As my punishment for the break in 7f15ebc7 (fixed in 752596b5) I'm
introducing this test to make sure it won't happen again. Currently,
only test for <graphics/> is supported.

Since we already have the v1.1.0-rc1 tag in git.

Free the old XML strings before overwriting them if the user
has chosen to reedit the file or force the redefinition.

Found by Alex Jia trying to reproduce another bug:
https://bugzilla.redhat.com/show_bug.cgi?id=977430#c3

virNetDevBridgeSetSTPDelay accepts delay in milliseconds,
but BSD implementation was expecting seconds. Therefore,
it was working correctly only with delay == 0.

This patch adds functionality to allow libvirt to configure the
'native-tagged' and 'native-untagged' modes on openvswitch networks.
Signed-off-by: NLaine Stump <laine@redhat.com>

I just learned that VFIO resets PCI devices when they are assigned to
guests / returned to the host, so it is redundant for libvirt to reset
the devices. This patch inhibits calling virPCIDeviceReset to devices
that will be/were assigned using VFIO.

The parameter specifies connection parameters to use for migrating
client's connection to domain's graphical console.

The patch implements wrappers for virDomainMigrate3 and
virDomainMigrateToURI3.

This patch introduces two new APIs virDomainMigrate3 and
virDomainMigrateToURI3 that may be used in place of their older
variants. These new APIs take optional migration parameters (such as
bandwidth, domain XML, ...) in an array of virTypedParameters, which
makes adding new parameters easier as there's no need to introduce new
APIs whenever a new migration parameter needs to be added. Both APIs are
backward compatible and will automatically use older migration calls in
case the new calls are not supported as long as the typed parameters
array does not contain any parameter which was not supported by the
older calls.

This patch implements extensible variants of all internal migration APIs
used for v3 migration.

To be used by new migration APIs with extensible set of parameters.

All APIs that take typed parameters are only using params address in
their entry point debug messages. With the new VIR_TYPED_PARAMS_DEBUG
macro, all functions can easily log all individual typed parameters
passed to them.

This API is useful for checking whether only a specific subset of
supported typed parameters were passed.

When unsupported parameter is passed to virTypedParamsValidate,
VIR_ERR_ARGUMENT_UNSUPPORTED should be returned rather than
VIR_ERR_INVALID_ARG, which is more appropriate for supported parameters
used incorrectly.