Querying destination migration statistics may result in getting
a failure or getting a elapsed time value depending on stats.status
value which is odd. Instead let's always fail. Clients should
be ready to handle this as currently getting failure period
can be considerable.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuMigrationFetchJobStatus is rather inconvinient. Some of its
callers don't need status to be updated, some don't need to update
elapsed time right away. So let's update status or elapsed time
in callers instead.

This patch drops updating job status on getting job stats by
client. This way we will not provide status 'completed' while
it is not yet updated by migration routine.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuMonitorGetMigrationStats will do it for us anyway.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This way we get stats only in one place. The former code waits for
complete/postcopy status basically and don't need to mess with stats.

The patch drops raising an error on stats updates failure. This
does not make much sense anyway.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Let's introduce QEMU_DOMAIN_JOB_STATUS_POSTCOPY state for job.current->status
instead of checking job.current->stats.status. The latter can be changed
when fetching migration statistics. Moving state function from the variable
and leave only store function seems more managable.

This patch removes all state checking usage of stats except for
qemuDomainGetJobStatsInternal. This place will be handled separately.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This patch simply switches code from using VIR_DOMAIN_JOB_* to
introduced QEMU_DOMAIN_JOB_STATUS_*. Later this gives us freedom
to introduce states for postcopy and mirroring phases.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemu driver does not have VIR_DOMAIN_JOB_BOUNDED jobs and
timeRemaining is always 0.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

msgmerge(1) and friends are required to build libvirt, so the
corresponding package should be installed in the Travis worker.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Keeping the list of build dependencies sorted alphabetically
makes it way easier to visually scan it for issues.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

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

Whenever a device is being updated via
virDomainUpdateDeviceFlags() API, we parse the device XML and
ideally run some generic checks to validate the configuration
(e.g. if device defines per-device boot order but the domain has
os/boot element already). Well, that's the theory - due to a
missing check we've jumped early from that check function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

After b4f7793c, qemuxml2xmltest has apparently become big enough
to trigger a compilation error when using --enable-test-coverage on
aarch64:

    CC       qemuxml2xmltest.o
  qemuxml2xmltest.c: In function 'mymain':
  qemuxml2xmltest.c:1216:1: error: const/copy propagation disabled: 4361 basic blocks and 99285 registers [-Werror=disabled-optimization]
   }
   ^
  qemuxml2xmltest.c:1216:1: error: PRE disabled: 4361 basic blocks and 99285 registers [-Werror=disabled-optimization]
  qemuxml2xmltest.c:1216:1: error: const/copy propagation disabled: 4361 basic blocks and 99285 registers [-Werror=disabled-optimization]
  qemuxml2xmltest.c:1216:1: error: const/copy propagation disabled: 4361 basic blocks and 99285 registers [-Werror=disabled-optimization]

However, as the GCC documentation states, this warning is not really
caused by issues in our code, so it makes sense to disable it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

Neither @cfg nor (now) @driver is used in the API, so remove them
and mark @opaque as UNUSED.

NB: Commit id 'fa3c5585' dropped the unused @qemuCaps which was the
last consumer of @driver other than @cfg, but even @cfg was never used
even in the original implementation from commit id 'd987f63a'.

arm/aarch64 -M virt on KVM doesn't and will never work with standard
VGA card emulation. The recommended method is to use type=virtio, so
let's make it the default for video devices without an explicit type
set by the user.

https://bugzilla.redhat.com/show_bug.cgi?id=1404112Signed-off-by: NCole Robinson <crobinso@redhat.com>

And not generic domain_conf code. We will need qemu private functions
in a bit.
Signed-off-by: NCole Robinson <crobinso@redhat.com>

This allows drivers to set their own default. But if a driver neglects
to fill one in, we still error like we previously would at parse time.
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Will be needed for future patches to pull the default video type
setting out of XML parsing routines.
Signed-off-by: NCole Robinson <crobinso@redhat.com>

There were a few places in our code where the following pattern in 'if'
condition occurred:

if ((foo = bar() < 0))
    do something;

This patch adjusts the conditions to the expected format:

if ((foo = bar()) < 0)
    do something;

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1488192Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

According to the comments in the file and the git history, the
list of forbidden symbols was originally built against Fedora 9
in 2009 (!) and pretty much never refreshed afterwards.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

Suggested-by: NMartin Kletzander <mkletzan@redhat.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

Although not previously explicitly documented, the expectation for
the libvirt event loop is that an implementation is registered early
in application startup, before calling any libvirt APIs and then
run forever after. Replacing a previously registered event loop is
not safe & subject to races even if virConnectClose has been called
on open handles, due to delayed deregistration of callbacks during
conenction close.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The libxslt package is needed since:

  commit 94d2d642
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed Jul 26 17:40:44 2017 +0100

    docs: make xmllint & xsltproc compulsory

The native RPM had it already, but mingw build was missing it.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Funny thing. So when initializing LXC driver's capabilities,
firstly the virLXCDriverGetCapabilities() is called. This creates
new capabilities, stores them under driver->caps, ref() them and
return them. However, the return value is ignored. Secondly, the
function is called yet again and since we have driver->caps set,
they are ref()-ed again an returned. So in the end, driver's
capabilities have refcount of three when in fact they should have
refcount of one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

* docs/news.xml: update for release
* po/*.po*: regenerated

If you use the VDDK library to access virtual machines remotely, you
really need to know the Managed Object Reference ("moref") of the VM.
This must be passed each time you connect to the API.

For example nbdkit's VDDK plugin requires a moref to be passed to
mount up a VM's disk remotely:

 nbdkit vddk user=root password=+/tmp/rootpw \
             server=esxi.example.com thumbprint=xx:xx:xx:... \
             vm=moref=2 \
             file="[datastore1] Fedora/Fedora.vmdk"

Getting the moref is a huge pain.  To get some idea of what it is, why
it is needed, and how much trouble it is to get it, see:
https://blogs.vmware.com/vsphere/2012/02/uniquely-identifying-virtual-machines-in-vsphere-and-vcloud-part-1-overview.html
https://blogs.vmware.com/vsphere/2012/02/uniquely-identifying-virtual-machines-in-vsphere-and-vcloud-part-2-technical.html

However the moref is available conveniently in the internals of the
libvirt VMX driver.  This patch exposes it as a custom XML element
using the same "vmware:" namespace which was previously used for the
datacenterpath (see libvirt commit 636a9905).

It appears in the XML like this:

<domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
  <name>Fedora</name>
...
  <vmware:datacenterpath>ha-datacenter</vmware:datacenterpath>
  <vmware:moref>2</vmware:moref>
</domain>

Note that the moref can appear as either a simple ID (for esx://
connections) or as a "vm-<ID>" (for vpx:// connections).  It should be
treated by users as an opaque string.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

commit '96e55048' caused make check failure for virschematest:

1929) Checking ../docs/news.xml against ../news.rng                     ... libvirt: XML Util error : XML document failed to validate against schema: Unable to validate doc against /home/jferlan/git/libvirt.work/docs/schemas/../news.rng
Datatype element summary has child elements
Element summary failed to validate content
Datatype element summary has child elements
Element summary failed to validate content
^[[31m^[[1mFAILED^[[0m

That's because <code> elements don't appear to be allowed in the schema.
Rather than attempt to fix the schema, figured it was simpler to just
remove them and let the schema fix happen later.

Documents some changes that have slipped through the cracks
during the development cycle.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This patch documents support for managedsave-dumpxml,
managedsave-define and managedsave-edit commands.
Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

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

In ace45e67 I tried to fix a problem that we get the reply to
a D-Bus call while we were sleeping. In that case the callback
was never set. So I changed the code that the callback is called
directly in this case. However, I hadn't realized that since the
callback is called out of order it locks the virNetDaemon.
Exactly the very same virNetDaemon object that we are dealing
with right now and that we have locked already (in
virNetDaemonAddShutdownInhibition())
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We call qemuDomainGetMachineName on domain start. On first
start (after daemon start) pid is 0 and virSystemdGetMachineNameByPID
don't get called. But after domain shutting down pid became -1 so
on next start virSystemdGetMachineNameByPID is called and returned an error.
Error is ignored so it is not critical. But at least on my system
(systemd-219 with extra patches) systemd-machined is crashed on
this request.

This behaviour is triggered by eaf2c9f8.
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

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

When updating a virtio enabled vNIC and trying to change either
of rx_queue_size or tx_queue_size success is reported although no
operation is actually performed. Moreover, there's no way how to
change these on the fly. This is due to way we check for changes:
explicitly for each struct member. Therefore it's easy to miss
one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NShuang He <shuang.he@zstack.io>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

Rather than using refreshVol which essentially only updates the
allocation, capacity, and permissions for the volume, but not
the format which does get updated in a pool refresh - let's use
the same helper that pool refresh uses in order to update the
volume target.

Create a separate function to handle the volume target update
via probe processing.

Currently while parsing domain XML we clear the UNIX path if it matches
one of the auto-generated paths by libvirt.  After that when the guest
is started new path is generated but the mode is also changed to "bind".

In the real-world use-case the mode should not change, it only happens
if a user provides a mode='connect' and path that matches one of the
auto-generated path or not provides a path at all.

Before *reconnect* feature was introduced there was no issue, but with
the new feature we need to make sure that it's used only with "connect"
mode, therefore we need to move the mode change into parsing in order
to have a proper error reported by validation code.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The test was introduced by 60135b22.

The auto-generated path is removed by post-parse callback which
also changes the mode from "connect" to "bind" since the auto-generated
path makes sense only for "bind" mode.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Missed by 9aa72a6d.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>