The passed function is meant to filter domains according to ACL match.

Extend it to a universal helper used for clearing lists of any objects.
Note that the argument type is specifically void * to allow implicit
typecasting.

Additionally add a helper that works on non-NULL terminated arrays once
we know the length.

Some platforms, like aarch64, don't have APIC but GIC. So there's
no reason to have <apic/> feature turned on. However, we are
still missing <gic/> feature. This commit introduces the feature
to XML parser and formatter, adds documentation and updates RNG
schema.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The phyp driver stuffed it into a DomainDefPtr during its attachdevice
routine, but the value is never advertised via capabilities so it should
be safe to drop.

Have the phyp driver use OSTYPE_LINUX, which is what it advertises via
capabilities.

We're about to allow IOThreads to be deleted, but an iothreadid may be
included in some domain thread sched, so add a new API to allow removing
an iothread from some entry.

Then during the writing of the threadsched data and an additional check
to determine whether the bitmap is all clear before writing it out.

Remove the iothreadspin array from cputune and replace with a cpumask
to be stored in the iothreadids list.

Adjust the test output because our printing goes in order of the iothreadids
list now.

Since it's only ever referenced in domain_conf.c, make the function
static, but also will need to move it to somewhere before it's referenced
rather than forward referencing it.

Add 'thread_id' to the virDomainIOThreadIDDef as a means to store the
'thread_id' as returned from the live qemu monitor data.

Remove the iothreadpids list from _qemuDomainObjPrivate and replace with
the new iothreadids 'thread_id' element.

Rather than use the default numbering scheme of 1..number of iothreads
defined for the domain, use the iothreadid's list for the iothread_id

Since iothreadids list keeps track of the iothread_id's, these are
now used in place of the many places where a for loop would "know"
that the ID was "+ 1" from the array element.

The new tests ensure usage of the <iothreadid> values for an exact number
of iothreads and the usage of a smaller number of <iothreadid> values than
iothreads that exist (and usage of the default numbering scheme).

Adding a new XML element 'iothreadids' in order to allow defining
specific IOThread ID's rather than relying on the algorithm to assign
IOThread ID's starting at 1 and incrementing to iothreads count.

This will allow future patches to be able to add new IOThreads by
a specific iothread_id and of course delete any exisiting IOThread.

Each iothreadids element will have 'n' <iothread> children elements
which will have attribute "id".  The "id" will allow for definition
of any "valid" (eg > 0) iothread_id value.

On input, if any <iothreadids> <iothread>'s are provided, they will
be marked so that we only print out what we read in.

On input, if no <iothreadids> are provided, the PostParse code will
self generate a list of ID's starting at 1 and going to the number
of iothreads defined for the domain (just like the current algorithm
numbering scheme).  A future patch will rework the existing algorithm
to make use of the iothreadids list.

On output, only print out the <iothreadids> if they were read in.

This is basically turning qemuDomObjEndAPI into a more general
function. Other drivers which gets a reference to domain objects may
benefit from this function too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This needs to specified in way too many places for a simple validation
check. The ostype/arch/virttype validation checks later in
DomainDefParseXML should catch most of the cases that this was covering.

But the internal API stays the same, and we just convert the value as
needed. Not useful yet, but this is the beginning step of using an enum
for ostype throughout the code.

When parsing XML, we validate the passed ostype + arch combo against
the detected hypervisor capabilities. This has led to the following
problem:

- Define x86 qemu guest
- qemu is inadvertently removed from the host
- libvirtd is restarted. fails to parse VM config since arch is removed
- 'virsh list --all' is now empty, user is wondering where their VMs went

Add a new internal flag VIR_DOMAIN_DEF_PARSE_SKIP_OSTYPE_CHECKS. Use
it when loading VM and snapshot configs from disk.

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

Operating systems use the identifier to name the disks. As the name
suggests the ID should be unique.

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

Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add VIR_DOMAIN_INPUT_BUS_PARALLELS device type
to handle domain configuration properly for
parallels containers, when VNC is enabled.

When domain configuration has at least one
'graphics', there should be mouse and keyboard.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

We support VNC for containers to have the same
interface with VMs. At this moment it just renders
linux text console.

Of course we don't pass any physical devices and
don't emulate virtual devices. Our VNC server
renders text from terminal master and sends
input events from VNC client to terminal.

So add special video type VIR_DOMAIN_VIDEO_TYPE_PARALLELS
for these pseudo-devices.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Instead of always using controller 0 and incrementing port number,
respect the maximum port numbers of controllers and use all of them.

Ports for virtio consoles are quietly reserved, but not formatted
(neither in XML nor on QEMU command line).

Also rejects duplicate virtio-serial addresses.
https://bugzilla.redhat.com/show_bug.cgi?id=890606
https://bugzilla.redhat.com/show_bug.cgi?id=1076708

Test changes:
* virtio-auto.args
  Filling out the port when just the controller is specified.
  switched from using
    maxport + 1
  to:
    first free port on the controller
* virtio-autoassign.args
  Filling out the address when no <address> is specified.
  Started using all the controllers instead of 0, also discards
  the bus value.
* xml -> xml output of virtio-auto
  The port assignment is no longer done as a part of XML parsing,
  so the unspecified values stay 0.

virDomainHasDiskMirror() currently detects only jobs that add the mirror
elements. Since some operations like migration are interlocked by
existing block jobs on the given domain the check needs to be
instrumented to check regular jobs too.

This patch renames virDomainHasDiskMirror to virDomainHasDiskBlockjob
and adds an argument that allows to select that it returns true only for
block copy jobs as those interlock making the domain persistent.

Other two uses trigger on any block job type.
Signed-off-by: NShanzhi Yu <shyu@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

When the synchronous pivot option is selected, libvirt would not update
the backing chain until the job was exitted. Some applications then
received invalid data as their job serialized first.

This patch removes polling to wait for the ABORT/PIVOT job completion
and replaces it with a condition. If a synchronous operation is
requested the update of the XML is executed in the job of the caller of
the synchronous request. Otherwise the monitor event callback uses a
separate worker to update the backing chain with a new job.

This is a regression since 1a92c719

When the ABORT job is finished synchronously you get the following call
stack:
 #0  qemuBlockJobEventProcess
 #1  qemuDomainBlockJobImpl
 #2  qemuDomainBlockJobAbort
 #3  virDomainBlockJobAbort

While previously or while using the _ASYNC flag you'd get:
 #0  qemuBlockJobEventProcess
 #1  processBlockJobEvent
 #2  qemuProcessEventHandler
 #3  virThreadPoolWorker

Recently we've fixed a bug where the status XML could not be parsed as
the parser used absolute path XPath queries. This test enhancement tests
all XML files used in the qemu-xml-2-xml test as a part of a status XML
snippet to see whether they are parsed correctly. The status XML-2-XML is
currently tested in 223 cases with this patch.

Add a few helpers that allow to operate with memory device definitions
on the domain config and use them to implement memory device coldplug in
the qemu driver.

This patch adds code that parses and formats configuration for memory
devices.

A simple configuration would be:
<memory model='dimm'>
  <target>
    <size unit='KiB'>524287</size>
    <node>0</node>
  </target>
</memory>

A complete configuration of a memory device:
<memory model='dimm'>
  <source>
    <pagesize unit='KiB'>4096</pagesize>
    <nodemask>1-3</nodemask>
  </source>
  <target>
    <size unit='KiB'>524287</size>
    <node>1</node>
  </target>
</memory>

This patch preemptively forbids use of the <memory> device in individual
drivers so the users are warned right away that the device is not
supported.

Dimm devices are described by the slot and base address. Add a new
address type to be able to describe such address.

Add a XML element that will allow to specify maximum supportable memory
and the count of memory slots to use with memory hotplug.

To avoid possible confusion and misuse of the new element this patch
also explicitly forbids the use of the maxMemory setting in individual
drivers's post parse callbacks. This limitation will be lifted when the
support is implemented.

virnetdevopenvswitch.h declares a few functions that can be called to
add ports to and remove them from OVS bridges, and retrieve the
migration data for a port. It does not contain any data definitions
that are used by domain_conf.h. But for some reason, domain_conf.h
virnetdevopenvswitch.h should be directly #including it. This adds a
few lines to the project, but saves all the files that don't need it
from the extra computing, and makes the dependencies more clear cut.

We're parsing memballoon status period as unsigned int, but when we're
trying to set it, both we and qemu use signed int.  That means large
values will get wrapped around to negative one resulting in error.
Basically the same problem as commit e3a7b874 was dealing with when
updating live domain.

QEMU changed the accepted value to int64 in commit 1f9296b5, but even
values as INT_MAX don't make sense since the value passed means seconds.
Hence adding capability flag for this change isn't worth it.

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

This one is no longer necessary since the Vcpu and IOThreads API's share

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

This one is no longer necessary since the Vcpu and IOThreads API's share

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

Since we're not specifically a vcpu related structure anymore...

As pointed out by jtomko in his review of the IOThreads pinning code:

http://www.redhat.com/archives/libvir-list/2015-March/msg00495.html

there are some comments sprinkled in indicating IOThreads were using
the same structure as the VcpuPin code...

This is the first patch of a few that will change the virDomainVcpuPin*
structures and code to just virDomainPin* - starting with the data
structure naming...