The error count statistic is not supported by qemu, so there's no need
to pass the variables around if the result is ignored anyways.

All the setters are the same code except for parameter name and
variable, so they can be converted to a macro to save a ton of
duplicated code.

Our code supports that for ages. When using a <filterref/> to an
<interface/> several parameters can be passed to the filter. Later,
when building firewall rules, parameters are substituted for their
values. However, our RNG schema allowed only one parameter to be
passed.
Reported-by: NBrian Rak <brak@gameservers.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

and their settings differ from common cpumask
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

If a domain object is being removed and looked up concurrently we must
ensure we unlock the object before unreferencing it, since the latter
might free the object.

The flaw was introduced in commit feb1a4d7.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

Undefining a running, autostarted domain removes the autostart link, but
dom->autostart is not cleared. If the domain is subsequently redefined,
libvirt thinks it is already autostarted and will not create the link
even if requested:

  # virsh dominfo example | grep Autostart
  Autostart:      enable

  # ls /etc/libvirt/qemu/autostart/example.xml
  /etc/libvirt/qemu/autostart/example.xml

  # virsh undefine example
  Domain example has been undefined

  # virsh define example.xml
  Domain example defined from example.xml

  # virsh dominfo example | grep Autostart
  Autostart:      enable

  # virsh autostart example
  Domain example marked as autostarted

  # ls /etc/libvirt/qemu/autostart/example.xml
  ls: cannot access /etc/libvirt/qemu/autostart/example.xml: No such file or directory

This commit ensures dom->autostart is cleared whenever the config and
autostart link (if present) are removed.

The bridge network driver cleared this flag itself in networkUndefine.
This commit moves this into virNetworkDeleteConfig for symmetry with
virDomainDeleteConfig, and to ensure it is not missed in future network
drivers.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

Error messages are already set in all code paths returning -1 from
networkGetNetworkAddress, so we don't want to overwrite them.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When creating qemu capabilities, a dummy virDomainObj is created just
because our monitor code expects that. However, the object is created
locked already. Then, under cleanup label, we simply unref the object
which results in whole domain object to be disposed. The object lock
is destroyed subsequently, but hey - it's still locked:

==24845== Thread #14's call to pthread_mutex_destroy failed
==24845==    with error code 16 (EBUSY: Device or resource busy)
==24845==    at 0x4C3024E: pthread_mutex_destroy (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==24845==    by 0x531F72E: virMutexDestroy (virthread.c:83)
==24845==    by 0x5302977: virObjectLockableDispose (virobject.c:237)
==24845==    by 0x5302A89: virObjectUnref (virobject.c:265)
==24845==    by 0x1DD37866: virQEMUCapsInitQMP (qemu_capabilities.c:3397)
==24845==    by 0x1DD37CC6: virQEMUCapsNewForBinary (qemu_capabilities.c:3481)
==24845==    by 0x1DD381E2: virQEMUCapsCacheLookup (qemu_capabilities.c:3609)
==24845==    by 0x1DD30F8A: virQEMUCapsInitGuest (qemu_capabilities.c:744)
==24845==    by 0x1DD31889: virQEMUCapsInit (qemu_capabilities.c:1020)
==24845==    by 0x1DD7DD36: virQEMUDriverCreateCapabilities (qemu_conf.c:888)
==24845==    by 0x1DDC57C0: qemuStateInitialize (qemu_driver.c:803)
==24845==    by 0x53DC743: virStateInitialize (libvirt.c:777)
==24845==
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

in virDomainFSInfoFree(), don't free the virDomainFSInfo data.

==10670== 80 bytes in 2 blocks are definitely lost in loss record 576 of 793
==10670==    at 0x4A06BC3: calloc (vg_replace_malloc.c:618)
==10670==    by 0x509DEBD: virAlloc (viralloc.c:144)
==10670==    by 0x19FBD558: qemuAgentGetFSInfo (qemu_agent.c:1837)
==10670==    by 0x1A03CF91: qemuDomainGetFSInfo (qemu_driver.c:19238)
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>

Test the whole range in testBit, not just the first bit.

Instead of finding the next clear bit by calling virBitmapGetBit
in a loop, use the virBitmapNextClearBit helper.

Commit 4bbe1029 fixed a problem in commit f7afeddc by moving the call
to virNetDevGetIndex() to a location common to all interface types (so
that the nicindex array would be filled in for macvtap as well as tap
interfaces), but the location was *too* common, as the original call
to virNetDevGetIndex() had been in a section qualified by "if
(cfg->privileged)". The result was that the "fixed" libvirtd would try
to call virNetDevGetIndex() even for session mode libvirtd, and end up
failing with the log message:

  Unable to open control socket: Operation not permitted

To remedy that, this patch qualifies the call to virNetDevGetIndex()
in its new location with cfg->privileged.

This resolves https://bugzilla.redhat.com/show_bug.cgi?id=1198244

As of bba93d40 all of our RPC objects are derived from
virObjectLockable. However, during rewrite some errors sneaked
in. For instance, the dispose functions to virNetClient and
virNetServerClient objects were not only freeing allocated
memory, but unlocking themselves. This is wrong. Object should
never disappear while locked.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

To prevent a confusion about missing chardev argument in qemu
command line add a note about that behavior into documentation.

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

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

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

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

Now that all the code uses accessors, don't expose the structure
anyway.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Well, one day this will be self-locking object, but not today.
But lets prepare the code for that! Moreover,
virNetworkObjListFree() is no longer needed, so turn it into
virNetworkObjListDispose().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The API will iterate over the list of network object and remove
desired ones from it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

An accessor following pattern laid out by virDomainObjList* APIs.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

An accessor following pattern laid out by virDomainObjList* APIs.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This API will be used in the future to call passed callback over
each network object in the list. It's slightly different to its
virDomainObjListForEach counterpart, because virDomainObjList
uses a hash table to store domain object, while virNetworkObjList
uses an array.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit v1.2.4-52-gda879e59 fixed issues with domains started before
sanlock driver was enabled by checking whether a running domain is
registered with sanlock and if it's not, sanlock driver is basically
ignored for the domain.

However, it was checking this even for domain which has just been
started and no sanlock_* API was called for them yet. This results in

    cmd 9 target pid 2135544 not found

error messages to appear in sanlock.log whenever we start a new domain.

This patch avoids this useless check for freshly started domains.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

virLockManager*New APIs are never called with
VIR_LOCK_MANAGER_USES_STATE. Moreover, lockd driver does not maintain
any state that would need to be transferred during migration and thus it
should not mention VIR_LOCK_MANAGER_USES_STATE at all.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Commit 5aee81a0 introduced a new test for disk-serial.  The test fails
on i686 arch because there is no need to add "-cpu qemu32" to command
line.  To fix the test update emulator in XML to "/usr/bin/qemu" so we
don't add the "-cpu qemu32" to command while running the test on i686 or
x86_64 host.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Follow-up to the IOThread review on CPU affinity map manipulation:

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

indicates that the GetEmulatorPinInfo could use similar algorithm adjustments
which is what this patch does.

Follow-up to the IOThread review on CPU affinity map manipulation:

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

indicates that the GetVcpuPinInfo could use similar algorithm adjustments
which is what this patch does.

By adding a call and check of return of virBitmapToData to the
IOThreads code, my Coverity checker lets me know qemuDomainHelperGetVcpus
also needs to check the status...

Based on review:

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

Adjust how the cpumap and cpumaplen to be returned are generated

We don't usually do tests purely for one change, but one change was
special because when users will migrate to OVMF/AAVMF, commit 18f9f69b
makes their lives easier by allowing them to interleave <type/> inside
<os/>.  It would be nice of us to keep the possibility of them pasting
the loader and nvram elements wherever it is valid, hence this test.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit 3e4b783e fixed an issue with RNG schema where this address type
was missing, this commit adds a test for it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>