Add helpers that will simplify checking if a backing file is valid or
whether it has backing store. The helper virStorageSourceIsBacking
returns true if the given virStorageSource is a valid backing store
member. virStorageSourceHasBacking returns true if the virStorageSource
has a backing store child.

Adding these functions creates a central points for further refactors.

The command "info migrate" of qemu outputs the dirty-pages-rate during
migration, but page size is different in different architectures. So
page size should be output to calculate dirty pages in bytes.

Page size is already implemented with commit
030ce1f8612215fcbe9d353dfeaeb2937f8e3f94 in qemu.
Now Implement the counter-part in libvirt.
Signed-off-by: NChao Fan <fanc.fnst@cn.fujitsu.com>
Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Note when no blockjobs are running in the status XML so that we know
that the backing chain will not change until we reconnect.

Currently we don't do it. Therefore we accept senseless
combinations of models and buses they are attached to.
Moreover, diag288 watchdog is exclusive to s390(x).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Checking of disk presence accesses storage on the host so it should be
done from the host setup function. Move the code to new function called
qemuProcessPrepareHostStorage and remove qemuDomainCheckDiskPresence.

Introduce a new function to prepare domain disks which will also do the
volume source to actual disk source translation.

The 'pretend' condition is not transferred to the new location since it
does not help in writing tests and also no tests abuse it.

Introduce a function to setup any TLS needs for a disk source.

If there's a configuration or other error setting up the disk source
for TLS, then cause the domain startup to fail.

For VxHS, follow the chardevTLS model where if the src->haveTLS hasn't
been configured, then take the system/global cfg->haveTLS setting for
the storage source *and* mark that we've done so via the tlsFromConfig
setting in storage source.

Next, if we are using TLS, then generate an alias into a virStorageSource
'tlsAlias' field that will be used to create the TLS object and added to
the disk object in order to link the two together for QEMU.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

VM private data is cleared when the VM is turned off and also when the
VM object is being freed. Some of the clearing code was duplicated.
Extract it to a separate function.

This also removes the now unnecessary function
qemuDomainClearPrivatePaths.

Commit 6801da94 fixed the typo in the function name, but forgot
to adjust the indentation level of the next line.

Because qemuDomainDefCopy needs a string representation of a domain
definition, there's no reason for calling the lower level
qemuDomainDefFormatBuf API.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

virDomainDefFormatInternal (called by qemuDomainDefFormatXMLInternal)
already checks for buffer errors and properly resets the buffer on
failure.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Commit id '99a2d6af' was a bit too aggressive with determining whether
the provided path was a "physical" cd-rom in order to generate a taint
message due to the possibility of some guest and host trying to control
the tray. For cd-rom guest devices backed to some VIR_STORAGE_TYPE_FILE
storage, this wouldn't be a problem and as such it shouldn't be a problem
for guest devices using some sort of block device on the host such as
iSCSI, LVM, or a Disk pool would present.

So before issuing a taint message, let's check if the provided path of
the VIR_STORAGE_TYPE_BLOCK backed device is a "known" physical cdrom name
by comparing the beginning of the path w/ "/dev/cdrom" and "/dev/sr".
Also since it's possible the provided path could resolve to some /dev/srN
device, let's get that path as well and perform the same check.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since commit v2.2.0-199-g7ce711a3 libvirt stores an updated guest CPU
in domain's live definition and there's no need to update it every time
we want to format the definition. The commit itself tried to address
this in qemuDomainFormatXML, but forgot to fix qemuDomainDefFormatLive.
Not to mention that masking a previously set flag is only acceptable if
the flag was set by a public API user. Internally, libvirt should have
never set the flag in the first place.

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

When a user requested a domain XML description with
VIR_DOMAIN_XML_UPDATE_CPU flag, libvirt would use the host CPU
definition from host capabilities rather than the one which will
actually be used once the domain is started.

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

In the past we updated host-model CPUs with host CPU data by adding a
model and features, but keeping the host-model mode. And since the CPU
model is not normally formatted for host-model CPU defs, we had to pass
the updateCPU flag to the formatting code to be able to properly output
updated host-model CPUs. Libvirt doesn't do this anymore, host-model
CPUs are turned into custom mode CPUs once updated with host CPU data
and thus there's no reason for keeping the hacks inside CPU XML
formatters.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

They are simply not supported on that machine type.

Partially-resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1487499Signed-off-by: NPino Toscano <ptoscano@redhat.com>

They are simply not supported on those architectures.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1487499Signed-off-by: NPino Toscano <ptoscano@redhat.com>

This will be used to improve the validation for this type of devices.

The former @def parameter is renamed to @dev, leaving @def for the
virDomainDef (following the style used elsewhere).
Signed-off-by: NPino Toscano <ptoscano@redhat.com>

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

Apart from generic checks, we need to constrain netmask/prefix
length a bit. Thing is, with current implementation QEMU needs to
be able to 'assign' some IP addresses to the virtual network. For
instance, the default gateway is at x.x.x.2, dns is at x.x.x.3,
the default DHCP range is x.x.x.15-x.x.x.30. Since we don't
expose these settings yet, it's safer to require shorter prefix
to have room for the defaults.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: laine@laine.org

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

Currently, all that users can specify for an interface type of
'user' is the common attributes: PCI address, NIC model (and
that's basically it). However, some need to configure other
address range than the default one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: laine@laine.org

Block job QMP commands with underscores rather than dashes were never
released in upstream qemu, (they were added, but modified in the same
release [1]), but a certain distro managed to backport the version in the
middle.

The change also slightly modified semantics for the abort command, which
made us have a lot of code which was only ever present in certain
downstream distros.

Clean the upstream code from the legacy cruft and support only the
upstream implementations.

[1] See qemu commit v1.0-2176-gdb58f9c060
Reviewed-by: NEric Blake <eblake@redhat.com>

No need to pass a @driver parameter since all that's done is deref
the @cfg especially since the only caller can just pass an already
referenced @cfg.

Also, looks like commit id '0298531b' at one time had a different
name for the API, so I took the liberty of fixing the comments too
since I would already be updating them for the @cfg variable.

In case of real migration (not migrating to file on save, dump etc)
migration info is not complete at time qemu finishes migration
in normal (non postcopy) mode. We need to update disks stats,
downtime info etc. Thus let's not expose this job status as
completed.

To archive this let's set status to 'qemu completed' after
qemu reports migration is finished. It is not visible as complete
job to clients. Cookie code on confirm phase will finally turn
job into completed. As we don't need more things to do when
migrating to file status is set to 'completed' as before
in this case.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When getting job info in case mirror does not reach ready phase
fetch mirror stats from qemu. Otherwise mirror stats are already
saved in current job.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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>