Instead of checking stat.status let's set status to migrating
as soon as migrate command is send (waiting for completion
is a good place too).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Setting status to none has little value - getting job status
will not return even elapsed time.

After this patch getting job stats stays correct in a sence
it will not fetch migration stats because it consults
stats.status before doing the fetch.
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>

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>

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>

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>

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>

When recreating folders with namespaces, the directory type was not
being handled at all.  It's not special, we probably just didn't know
that that can be used as a volume path as well.  The code failed
gracefully, but we want to allow that so that we can use <disk
type='dir'> in domains again.

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

At some places we either already have synchronous job or we just
released it. Also, some APIs might want to use this code without
having to release their job. Anyway, the job acquire code is
moved out to qemuDomainRemoveInactiveJob so that
qemuDomainRemoveInactive does just what it promises.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Otherwise longer domain names might generate paths that are too long
to be created.  This follows what other parts of the code do as well.

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

The reconnect attribute for chardev devices in QEMU is used to
configure the reconnect timeout in seconds.  Setting '0' value disables
the reconnect functionality thus we don't allow to set '0' for QEMU.
To disable the reconnect user should use <reconnect enabled='no'/>.

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

And into DeviceDefValidate which is the expected place
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Use the new facility which allows to ignore failures in post parse
callbacks if they are not fatal so that VM configs are not lost if the
emulator binary is missing.

If qemuCaps can't be populated on daemon restart skip certain portions
of the post parse callbacks during config reload and re-run the callback
during VM startup.

This fixes VMs vanishing if the emulator binary was broken or
uninstalled and libvirtd was restarted.

qemuDomainControllerDefPostParse assigns the default USB controller
model when it was not specified by the user. Skip this step if @qemuCaps
is missing so that we don't fill wrong data. This will then be fixes by
re-running the post parse callback.

Return NULL in qemuDomainDefaultNetModel if qemuCaps is missing and the
network card model would be determined by the capabilities.

The domain post parse callback, domain address callback and the domain
device callback (for every single device) would each grab qemuCaps for
the current emulator. This is quite wasteful. Use the new callback to do
this just once.

We're storing the machine name in @priv but free it just in
qemuProcessStop, Therefore this may leak.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Just like I've added support for setting rx_queue_size (in
c56cdf25 and friends), qemu just gained support for setting tx
ring size.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is a preparation for following patches where we switch to
virFileCache for QEMU capabilities cache

The host arch will always remain the same but virCaps may change.  Now
the host arch is stored while creating new qemu capabilities cache.
It removes the need to pass virCaps into virQEMUCapsCache*() functions.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Introduced by commit 'a7bc2c8c'.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

It's possible to have more than one unnamed virtio-serial unix channel.
We need to generate a unique name for each channel. Currently, we use
".../unknown.sock" for all of them. Better practice would be to specify
an explicit target path name; however, in the absence of that, we need
uniqueness in the names we generate internally.

Before the changes we'd get /var/lib/libvirt/qemu/channel/target/unknown.sock
for each instance of
    <channel type='unix'>
        <source mode='bind'/>
        <target type='virtio'/>
    </channel>

Now, we get vioser-00-00-01.sock, vioser-00-00-02.sock, etc.
Signed-off-by: NScott Garfinkle <seg@us.ibm.com>

It is more related to a domain as we might use it even when there is
no systemd and it does not use any dbus/systemd functions.  In order
not to use code from conf/ in util/ pass machineName in cgroups code
as a parameter.  That also fixes a leak of machineName in the lxc
driver and cleans up and de-duplicates some code.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This way we can finally make it static and not use any externs anywhere.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This will help us to get to some data more easily.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The original name didn't hint at the fact that PHBs are
a pSeries-specific concept.
Suggested-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

This patch addresses the same aspects on PPC the bug 1103314 addressed
on x86.

PCI expander bus creates multiple primary PCI busses, where each of these
busses can be assigned a specific NUMA affinity, which, on x86 is
advertised through ACPI on a per-bus basis.

For SPAPR, a PHB's NUMA affinities are assigned on a per-PHB basis, and
there is no mechanism for advertising NUMA affinities to a guest on a
per-bus basis. So, even if qemu-ppc manages to get some sort of multi-bus
topology working using PXB, there is no way to expose the affinities
of these busses to the guest. It can only be exposed on a per-PHB/per-domain
basis.

So patch enables NUMA node tag in pci-root controller on PPC.

The way to set the NUMA node is through the numa_node option of
spapr-pci-host-bridge device. However for the implicit PHB, the only way
to set the numa_node is from the -global option. The -global option applies
to all the PHBs unless explicitly specified with the option on the
respective PHB of CLI. The default PHB has the emulated devices only, so
the patch prevents setting the NUMA node for the default PHB.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Decouple them by storing them in the XML separately rather than
regenerating them. This will simplify upcoming fixes.

Move the code to separate functions to avoid complicating the existing
ones with changes.

Now that the multi-phb support series is in, work on the TODO at
qemuDomainGetMemLockLimitBytes() to arrive at the correct memlock limit
value.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

pSeries guests will soon be allowed to have multiple
PHBs (pci-root controllers), meaning the current check
on the controller index no longer applies to them.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

pSeries guests will soon be allowed to have multiple
PHBs (pci-root controllers), which of course means that
all but one of them will have a non-zero index; hence,
we'll need to relax the current check.

However, right now the check is performed in the conf
module, which is generic rather than tied to the QEMU
driver, and where we don't have information such as the
guest machine type available.

To make this change of behavior possible down the line,
we need to move the check from the XML parser to the
drivers. Luckily, only QEMU and bhyve are using PCI
controllers, so this doesn't result in much duplication.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

When checking ABI stability between two domain definitions, we first
make migratable copies of them. However, we also asked for the guest CPU
to be updated, even though the updated CPU is supposed to be already
included in the original definitions. Moreover, if we do this on the
destination host during migration, we're potentially updating the
definition with according to an incompatible host CPU.

While updating the CPU when checking ABI stability doesn't make any
sense, it actually just worked because updating the CPU doesn't do
anything for custom CPUs (only host-model CPUs are affected) and we
updated both definitions in the same way.

Less then a year ago commit v2.3.0-rc1~42 stopped updating the CPU in
the definition we got internally and only the user supplied definition
was updated. However, the same commit started updating host-model CPUs
to custom CPUs which are not affected by the request to update the CPU.
So it still seemed to work right, unless a user upgraded libvirt 2.2.0
to a newer version while there were some domains with host-model CPUs
running on the host. Such domains couldn't be migrated with a user
supplied XML since libvirt would complain:

    Target CPU mode custom does not match source host-model

The fix is pretty straightforward, we just need to stop updating the CPU
when checking ABI stability.

https://bugzilla.redhat.com/show_bug.cgi?id=1463957Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Obviously, old gcc-s ale sad when a variable shares the name with
a function. And we do have such variable (added in 4d8a914b):
@mount. Rename it to @mountpoint so that compiler's happy again.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The way we create devices under /dev is highly linux specific.
For instance we do mknod(), mount(), umount(), etc. Some
platforms are even missing some of these functions. Then again,
as declared in qemuDomainNamespaceAvailable(): namespaces are
linux only. Therefore, to avoid obfuscating the code by trying to
make it compile on weird platforms, just provide a non-linux stub
for qemuDomainAttachDeviceMknodRecursive(). At the same time,
qemuDomainAttachDeviceMknodHelper() which actually calls the
non-existent functions is moved under ifdef __linux__ block since
its only caller is in that block too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

The helper methods for actually accessing the storage objects don't
really belong to the main storage driver implementation file. Split them
out.