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.

Unlike create options, if the file to be removed is already in the
pool, then the uid/gid will come from the pool. If it's the same as the
currently running process, then just do the unlink/rmdir directly
rather than going through the fork processing unnecessarily

qemu-kvm can be used to run ppc64 guests on ppc64le hosts and vice
versa, since the hardware is actually the same and the endianness
is chosen by the guest kernel.

Up until now, however, libvirt didn't allow the use of qemu-kvm
to run guests if their endianness didn't match the host's.

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

Commit 792f81a4 caused a regression in the libssh2 host key
verification code by changing the variable type of 'i' to unsigned.
Since one of the loops used -1 as a special value if the asking
callback was found the conversion made a subsequent test always fail.

The bug was stealth enough to pass review, compilers and coverity.

Refactor the condition to avoid problems.

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

Rename the function to virDomainDefCheckDuplicateDiskInfo and make it
check disk serials too.

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

Since we'd disallow migration of a guest that would have possibly
invalid config but still be able to work, relax the WWN check to be
performed only on new starts of the VM.

If a system has a large number of active or active interfaces, it can
be a big waste of time to retrieve and qualify all interfaces if the
caller only wanted one subset. Since netcf has a simple flag for this,
translate the libvirt flag into a netcf flag and let netcf pre-filter.

Getting the MAC address of an interface is actually fairly expensive,
and we've already gotten it and stored it into def, so just keep def
around a bit longer and retrieve it from there.

This reduces the time for "virsh iface-list --all" from 28 to 23
seconds when there are 400 interfaces.

The spec for virConnectListAllInterfaces says that if the pointer that
is supposed to hold the list of interfaces is NULL, the function
should just return the count of interfaces that matched the filter,
but the code never increments the count if the list pointer is NULL.

In previous change:

  commit 29b51674
  Author: Jiri Denemark <jdenemar@redhat.com>
  Date:   Tue Aug 4 14:05:52 2015 +0200

    examples: Add example polkit ACL rules

The polkit examples were accidentally added to the spec inside
a %if %{with_network} conditional.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We are using memory-backing-file even when it's not needed, for example
if user requests hugepages for memory backing, but does not specify any
pagesize or memory node pinning.  This causes migrations to fail when
migrating from older libvirt that did not do this.  So similarly to
commit 7832fac8 which does it for
memory-backend-ram, this commit makes is more generic and
backend-agnostic, so the backend is not used if there is no specific
pagesize of hugepages requested, no nodeset the memory node should be
bound to, no memory access change required, and so on.

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