Rework the code such that virDomainObjListFindByID will always
return a locked/ref counted object so that the callers can
always do the same cleanup logic to call virDomainObjEndAPI.
Makes accessing the objects much more consistent.

NB:
There were 2 callers (lxcDomainLookupByID and qemuDomainLookupByID)
that were already using the ByID name, but not virDomainObjEndAPI -
these were changed as well in this update/patch.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

Now that every caller is using virDomainObjListFindByUUIDRef,
let's just remove it and keep the name as virDomainObjListFindByUUID.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

The "git-publish" tool is a useful git extension for sending patch
series for code review. It automatically creates versioned tags
each time code on a branch is sent, so that there is a record of
each version. It also remembers the cover letter so it does not
need re-entering each time the series is reposted.

With this config file present it is now sufficient[1] to run

  $ git publish

to send all patches in a branch to the list for review

[1] Assuming your $HOME/.gitconfig has an SMTP server listed
at least e.g.

   [sendemail]
        smtpserver = smtp.example.com
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Many of the old xm and sexpr test files used qemu-dm as the emulator.
Modern Xen systems no longer use the old, forked qemu-dm, instead
preferring the distro provided qemu or an "upstream" qemu that is
built when the Xen tools are built. This qemu is typically installed
in /usr/lib/xen/bin/qemu-system-i386.

The libxl test files already use /usr/lib/xen/bin/qemu-system-i386.
For consistency, change the old test files to use the same emulator
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

For vzDomainLookupByID and vzDomainLookupByUUID let's
return a locked and referenced @vm object so that callers
can then use the common and more consistent virDomainObjEndAPI
in order to handle cleanup rather than needing to know that the
returned object is locked and calling virObjectUnlock.

The LookupByName already returns the ref counted and locked object,
so this will make things more consistent.

Also adjust the prlsdkHandle{VmState|VmRemoved|Perf}Event APIs
in the same manner.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Rather than have two API's doing different things for different
callers, let's make one API that will always return a locked and
ref counted object. That way, the callers will always know that
they must call virDomainObjEndAPI and not have to decide whether
they should call virObjectUnlock instead.

This will make things consistent with LookupByName which returns
the locked and ref counted object.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

For vmwareDomObjFromDomainLocked and vmwareDomainLookupByID
let's return a locked and referenced @vm object so that callers
can then use the common and more consistent virDomainObjEndAPI
in order to handle cleanup rather than needing to know that the
returned object is locked and calling virObjectUnlock.

The LookupByName already returns the ref counted and locked object,
so this will make things more consistent.

For vmwareDomainUndefineFlags and vmwareDomainShutdownFlags since
virDomainObjListRemove will return an unlocked object, we need to
relock before making the EndAPI call.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

If vmwareDomainLookupByID or vmwareDomainLookupByName fails
to find a vm, let's be a bit more descriptive by providing
the failing id or name in the error message.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Rather than repeat code throughout, create and use a couple of
accessors in order to lookup by UUID.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The virDomainObjListFindByName returns a locked and reffed
domain object, all we did was unlock it, leaving an extra
ref. Use the virDomainObjEndAPI to cleanup instead.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The generated source files for dispatching libvirtd RPC messages contain
translations and are thus listed in POTFILES. This means they are
required in order to build libvirt.pot. Rather than changing the files
that go into libvirt.pot dynamically, just unconditionally build the
remote driver sources so they are always available for building
libvirt.pot. This ensures we don't silently loose translation messages
based on configure args.

This fixes the mingw build which needs to create libvirt.pot but has
libvirtd disabled.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

While working on discard feature I've noticed some long lines
that should be wrapped.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When writing the VMX file from the domain XML, write
cpuid.coresPerSocket if there is a specified CPU topology in the guest.

Use the domain XML of esx-in-the-wild-9 in vmx2xml as testcase for
xml2vmxtest.
Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Acked-by: NRichard W.M. Jones <rjones@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Convert the cpuid.coresPerSocket key as both number of CPU sockets, and
cores per socket.

Add the VMX file attached to RHBZ#1568148 as testcase esx-in-the-wild-9;
adapt the resulting XML of testcase esx-in-the-wild-8 to the CPU
topology present in that VMX.

https://bugzilla.redhat.com/show_bug.cgi?id=1568148Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Acked-by: NRichard W.M. Jones <rjones@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Commit id '6df5d777' somehow during the move from one branch to
another added an erroneous '!'...
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

For umlDomObjFromDomainLocked and umlDomainLookupByID let's
return a locked and referenced @vm object so that callers
can then use the common and more consistent virDomainObjEndAPI
in order to handle cleanup rather than needing to know that the
returned object is locked and calling virObjectUnlock. This
means for some consumers we need to relock the @dom after a
virDomainObjListRemove, but before calling virDomainObjEndAPI.

The LookupByName already returns the ref counted and locked object,
so this will make things more consistent.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Rather than an empty failed to find, let's provide a bit more
knowledge about what we failed to find by using the name string
or the id value.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Rather than repeat code throughout, create and use a couple of
accessors in order to lookup by UUID. This will also generate
a common error message including the failed uuidstr for lookup
rather than just returning nothing in some instances.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The virDomainObjListFindByName will return a locked and reffed
object. If we call virDomainObjListRemove that will unlock the
object upon return, thus we need to relock the object before
making the call to virDomainObjEndAPI.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

There's no need to check if @dom exists before trying to
call virDomainObjListRemove since it must exist due to
prior checks.

Additionally, if we do remove the @dom, then set it to NULL
so that the virObjectUnlock isn't referencing something that
is deleted.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If virJSONValueArraySize(caps) <= 0, then we will still need to
virJSONValueFree(caps) because qemuMonitorSetMigrationCapabilities
won't consume it.

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

If @client hasn't been opened, then don't call virNetServerClientClose
since that'll cause certain failure.

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

If @log is not fopen'd then, going to cleanup and calling fclose
will make for an unhappy callee. So just fail immediately instead
since there's nothing to clean up.

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

Move to within the #if since the #else portion ends with a goto
and that raised concern by Coverity.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id '43f2ccdc' called virDomainDiskSourceDefFormatInternal
rather than formatting the the disk source inline. However, it
did not handle the case where the helper failed. Over time the
helper has been renamed to virDomainDiskSourceFormat. Similar to
other consumers, if virDomainDiskSourceFormat fails, then the
formatting could be off, so it's better to fail than to continue
on with some possibly bad data. Alter the function and the caller
to check status and jump to error in that case.

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

The code is generic enough to be reused. Move it into a
separate function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

So far all the properties we are trying to fetch are device
properties, i.e. -device $dev on qemu command line. Change
misleading variable names to express what's queried for better.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The current private XML parsing code relies on the assumption
that NUMA node IDs start from 0 and are densely allocated,
neither of which is necessarily the case.

Change it so that the bitmap size is dynamically calculated by
looking at NUMA node IDs instead, which ensures all nodes will
be able to fit and thus the bitmap will be parsed successfully.

Update one of the test cases so that it would fail with the
previous approach, but passes with the new one.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490158Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

vircapstest has code to add a full host NUMA topology, that
is, one that includes all information about nodes and CPUs
including IDs; testQemuCapsInit(), which is used to create a
mock virCapsPtr for QEMU tests, however, just fakes it by
setting nnumaCell_max to some number.

While the latter approach has served us well so far, we're
going to need all the information to be filled in soon. In
order to do that, we can just move the existing code from
vircapstest to testutils and, with some renaming and
trivial tweaking, use it as-is.

Interestingly, the NUMA topology generated by the function
is rigged up so that the NUMA nodes aren't (necessarily)
numbered starting from 0, which is a nice way to spot
mistaken assumptions in our codebase.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Allocated in qemuMigrationParamsNew() we need to free
priv->job.migParams when no longer needed.

==8061== 234 (192 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 112 of 123
==8061==    at 0x4C2CF26: calloc (vg_replace_malloc.c:711)
==8061==    by 0x5325D05: virAlloc (viralloc.c:144)
==8061==    by 0x1984F9: qemuMigrationParamsNew (qemu_migration_params.c:218)
==8061==    by 0x19A352: qemuMigrationParamsParse (qemu_migration_params.c:1185)
==8061==    by 0x1604D8: qemuDomainObjPrivateXMLParseJob (qemu_domain.c:2390)
==8061==    by 0x160AE9: qemuDomainObjPrivateXMLParse (qemu_domain.c:2517)
==8061==    by 0x5419EAE: virDomainObjParseXML (domain_conf.c:20442)
==8061==    by 0x541A25E: virDomainObjParseNode (domain_conf.c:20555)
==8061==    by 0x541A2FC: virDomainObjParseFile (domain_conf.c:20574)
==8061==    by 0x13607D: testCompareStatusXMLToXMLFiles (qemuxml2xmltest.c:75)
==8061==    by 0x14F3E8: virTestRun (testutils.c:180)
==8061==    by 0x14DCD0: mymain (qemuxml2xmltest.c:1200)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The .pot, .po and .gmo files are slightly unusual in that we generate
them in the srcdir when building form git. This is because they'll be
bundled in the tar archive, so a build-from-tar will see them in srcdir.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>