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>

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>

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>

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>

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>

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>

This commit adds qemu driver implementation to edit xml
configuration of managed save state file of a domain.
Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>

This commit adds qemu driver implementation to get xml description
for managed save state domain.
Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>

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

For some reason, we completely ignore <on_reboot/> setting for
domains. The implementation is simply not there. It never was.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This API is definitely modifying state of @vm. Therefore it
should grab a job.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@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>

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

Signed-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>

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

We can't retrieve the isolation group of a device that's not present
in the system. However, it's very common for VFs to be created late
in the boot, so they might not be present yet when libvirtd starts,
which would cause the guests using them to disappear.

Moreover, for other architectures and even ppc64 before isolation
groups were introduced, it's considered perfectly fine to configure a
guest to use a device that's not yet (or no longer) available to the
host, with the obvious caveat that such a guest won't be able to
start before the device is available.

In order to be consistent, when a device's isolation group can't be
determined fall back to not isolating it rather than erroring out or,
worse, making the guest disappear.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1484254Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

To handle setting a default heads value. Convert callers that were
doing it by hand
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NCole Robinson <crobinso@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>

The ram/vram = 0 bits aren't needed, and PostParse will fill in the
needed QXL default
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Both of these are dead code: qemu_command.c explicitly rejects
VIRT_XEN earlier in the call chain, and qemu_parse_command.c
will never set VIRT_XEN anymore
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Add code to support querying maximum allowable downtime during live migration.

This is more user-friendly because the error will be
displayed directly instead of being buried in the log.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@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.

Report the given GIC version as unsupported if @qemuCapsi is NULL. This
will be helpful to run post parse callbacks even if qemu is not
currently installed.

If qemuCaps are not present, just return the original machine type name.

This will help in situations when qemuCaps is not available in the post
parse callback.

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.

Offline migration transfers only the domain definition.

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

If an environment specific _tls_x509_cert_dir is provided, then
do not VIR_STRDUP the defaultTLSx509secretUUID as that would be
for the "default" environment and not the vnc, spice, chardev, or
migrate environments. If the environment needs a secret to decode
it's certificate, then it must provide the secret. If the secrets
happen to be the same, then configuration would use the same UUID
as the default (but we cannot assume that nor can we assume that
the secret would be necessary).

The correct lock order is:

  nwfilter driver lock (not used in this code path)
  nwfilter update lock
  virt driver lock (not used in this code path)
  domain object lock

but the current code have this order:

  domain object lock
  nwfilter update lock
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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