Commit 4e803227 used $(builddir) in the header search
path to fix a build issue; however, $(builddir) is not defined
by old autoconf versions such as the one available in CentOS 5,
resulting in the following error:

  cc1: error: /util: No such file or directory
  make[3]: *** [libvirt_driver_la-fdstream.lo] Error 1

Since $(builddir) is defined to always be '.', just use that
value directly instead.

Since a9fe6203, we are generating virkeymaps.h at build
time; however, we are not including $(builddir)/util in the
header search path, so when doing a VPATH build the compiler
is unable to locate the file.

make[2]: Entering directory
`/home/jenkins/libvirt/systems/libvirt-fedora-20/build/src'
  GEN      util/virkeymaps.h
  ...
  CC       util/libvirt_util_la-virkeycode.lo
  CC       util/libvirt_util_la-virkeyfile.lo
  CC       util/libvirt_util_la-virlockspace.lo
  CC       util/libvirt_util_la-virlog.lo
../../src/util/virkeycode.c:27:24: fatal error: virkeymaps.h: No such file or directory
 #include "virkeymaps.h"
                        ^
compilation terminated.

Remove unused definitions, functions and structure fields.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Cleanup calls to virStorageBackendCopyToFD a bit.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Coverity notices that net->ifname is potentially referenced after a
VIR_FREE().  Since the net->ifname will eventually be free'd during
virDomainDefFree when calling virDomainNetDefFree, let's just that
processing take care the free.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since the strtok_r call in libxlCapsInitGuests expects a non NULL first
parameter when the third parameter is NULL, we need to check that
the returned 'capabilities' from a libxl_get_version_info call is
not NULL and error out if so since the code expects it.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

So imagine you want to crate new security manager:

  if (!(mgr = virSecurityManagerNew("selinux", "QEMU", false, true, false, true)));

Hard to parse, right? What about this:

  if (!(mgr = virSecurityManagerNew("selinux", "QEMU",
                                    VIR_SECURITY_MANAGER_DEFAULT_CONFINED |
                                    VIR_SECURITY_MANAGER_PRIVILEGED)));

Now that's better! This is what the commit does.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We can ignore the result of virtTestResult here, because failure is
unconditionally reported by the callers

Two #define lines introduced by b527aa09 did not respect the
indentation rules, thus breaking syntax-check.

This gets rid of the partially enforced alignment and makes it less
likely for a bogus value to be introduced in the enumeration.
Capabilities are divided in five-element groups for better readability.

Use #define for QEMU_CAPS_NET_NAME and QEMU_CAPS_HOST_NET_ADD, both
of which are aliases for QEMU_CAPS_0_10.

qemuMigrationIsAllowed would disallow offline migration if the VM
contained host devices or memory modules. Since during offline migration
we don't transfer any state we can safely migrate VMs with such
configuration.

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

Use the migration @flags for checking various migration aspects rather
than picking them out as booleans. Document the new semantics in the
function header.

Now that qemuMigrationIsAllowed is always called with @vm, we can drop
the @def argument and simplify the control flow.

Additionally the comment is invalid so drop it.

Extract the hostdev check from qemuMigrationIsAllowed into a separate
function since that is the only part that needs to be done in the v2
migration protocol prepare phase on the destination. All other checks
were added when the v3 protocol existed so they don't need to be
extracted.

This change will allow to drop the @def argument for
qemuMigrationIsAllowed and further simplify the function.

I'm hitting this little annoyance in fedora's package repo:

$ fedpkg prep
Downloading libvirt-1.2.20.tar.gz
...
+ /usr/bin/gzip -dc /home/crobinso/src/fedora/libvirt/libvirt-1.2.20.tar.gz
$ git clean -xdf
Removing libvirt-1.2.20.tar.gz
Skipping repository libvirt-1.2.20/

We git-ify the libvirt directory as part of applying patches in the spec
file, but 'git clean' will ignore subfolders that appear to be standalone
git repos.

Let's just delete the .git directory after we're done with it.

In fact, it was never used as far as vz has no features supporting it.
That is why there will be no harm to anyone if we just remove this code to
prevent further misunderstanding and efforts to support dead code.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

At the time this code was added we had intentions to support libvirt interface
to manage vz networks. In fact, it was never implemented completely to work
correctly that makes me think that there will be no harm to anyone if we just
rip it off. Moreover, in vz7 we started to use libvirt bridge network driver to
manage networks.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

- qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default
  to virtio-mmio even if qemu is new enough to support PCI
- qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args

The example pvspinlock XML is:

  <pvspinlock/>

While this is accepted by libvirt and works correctly, it's currently
always output as a tristate like

  <pvspinlock state='on'/>

So document that format instead

Even though QEMU on the source host reports completed migration and thus
we move to the Finish phase, QEMU on the destination host may still be
processing migration data. Thus before we can start guest CPUs on the
destination, we have to wait for a completed migration event.

https://bugzilla.redhat.com/show_bug.cgi?id=1265902Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

With new QEMU which supports migration events,
qemuMigrationCheckJobStatus needs to explicitly query QEMU for migration
statistics once migration is completed to make sure the caller sees
up-to-date statistics with both old and new QEMU. However, some callers
are not interested in the statistics at all and once we start waiting
for a completed migration on the destination host too, checking the
statistics would even fail. Let's push the decision whether to update
the statistics or not to the caller.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function already has two bool parameters and we will need to add a
new one. Let's switch to flags to make the callers readable.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The destination host gets detailed statistics about the current
migration form the source host via migration cookie and copies them to
the domain object so that they can be queried using
virDomainGetJobStats. However, we should only copy statistics to the
domain object when migration finished successfully.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Even if we are migrating a domain with VIR_MIGRATE_PAUSED flag set, we
should still update the total time of the migration. Updating downtime
doesn't hurt either, even though we don't actually start guest CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We are distributing virkeymaps.h and all the tools needed to rebuild
that file.  On top of that, we are generating that file into the
$(srcdir) and that sometimes fails when trying to do make dist in VPATH
on rawhide fedora.  And we don't clean the file when maintainer-clean
make target is requested.  So let's not distribute the file and rather
let everyone rebuild it when needed and clean it when appropriate.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

profile_status function was not making any difference between error
cases and unconfined profiles. The problem with this approach is that
dominfo was throwing an error on unconfined domains.

Our docs state that subelements of <metadata> shall have a namespace
and the medatata APIs expect that too. To avoid inaccessible
<metadata> sub-elements, just remove those that don't conform to the
documentation.

Apart from adding the new condition this patch renames the function and
refactors the code flow to allow the changes.

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

virtTestResult is suboptimal for a few reasons:

- It poorly duplicates virtTestRun pass/fail reporting logic
- It doesn't have virtTestRun's alloc testing support
- It only reports the test name _after_ the test has run.
- It doesn't follow the standard virtTestRun pattern that most other
  tests use.

There's no users left, so drop it. If any other async tests like eventtest
spring up that don't cleanly fit the virtTestRun pattern, I suggest they
just open code the support for it around virtTestRun

These event tests aren't run synchronously, so there isn't an obvious
function to pass to virtTestRun. Instead, open code roughly what
virtTestResult did before: printing an error message if a test failed.

Instead use the same pattern that most other test files use.

Helps to visually track down test failures if debugging the test suite.

The colors match what 'make check' does for pass/fail/skip

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

Calculation of the extended and logical partition values for the disk
pool is complex. As the bz points out an extended partition should have
it's allocation initialized to 0 (zero) and keep the capacity as the size
dictated by the extents read.  Then for each logical partition found,
adjust the allocation of the extended partition.

Finally, previous logic tried to avoid recalculating things if a logical
partition was deleted; however, since we now have special logic to handle
the allocation of the extended partition, just make life easier by reading
the partition table again - rather than doing the reverse adjustment.

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

When 'starting' up a disk pool, we need to make sure the label on the
device is valid; otherwise, the followup refreshPool will assume the
disk has been properly formatted for use. If we don't find the valid
label, then refuse the start and give a proper reason.

Let's check to ensure we can find the Partition Table in the label
and that libvirt actually recognizes that type; otherwise, when we
go to read the partitions during a refresh operation we may not be
reading what we expect.

This will expand upon the types of errors or reason that a build
would fail, so we can create more direct error messages.

Modify virStorageBackendDiskValidLabel to add a 'writelabel' parameter.
While initially for the purpose of determining whether the label should
be written during DiskBuild, a future use during DiskStart could determine
whether the pool should be started using the label found. Augment the
error messages also to give a hint as to what someone may need to do
or why the command failed.

Create a new function virStorageBackendDiskValidLabel to handle checking
whether there is a label on the device and whether it's valid or not.
While initially for the purpose of determining whether the label can be
overwritten during DiskBuild, a future use during DiskStart could determine
whether the pool should be started using the label found.

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

Although perhaps bordering on a don't do that type scenario, if
someone creates a volume in a pool outside of libvirt, then uses that
same name to create a volume in the pool via libvirt, then the creation
will fail and in some cases cause the same name volume to be deleted.

This patch will refresh the pool just prior to checking whether the
named volume exists prior to creating the volume in the pool. While
it's still possible to have a timing window to create a file after the
check - at least we tried.  At that point, someone is being malicious.

As it turns out the caller in this case expects a return < 0 for failure
and to get/use "errno" rather than using the negative of returned status.
Again different than the create path.

If someone "deleted" a file from the pool without using virsh vol-delete,
then the unlink/rmdir would return an error (-1) and set errno to ENOENT.
The caller checks errno for ENOENT when determining whether to throw an
error message indicating the failure.  Without the change, the error
message is:

error: Failed to delete vol $vol
error: cannot unlink file '/$pathto/$vol': Success

This patch thus allows the fork path to follow the non-fork path
where unlink/rmdir return -1 and errno.