We want the signatures to be consistent, and also we're
going to start using the additional parameter next.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Make sure related functions, eg. all qemuDomainIs*(), are
close together instead of being sprinkled throughout both
the header and implementation file, and also that all
qemuDomainMachine*() functions are declared first since
we're going to make a bunch of them static later on.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

While the chances of the current checks resulting in false
positives are basically zero, it's still nicer to check for
the full prefix instead of the prefix's prefix.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

No need to check whether we're dealing with a pSeries guest
twice within just a few lines.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

For consistency, let's use the semicolon for all definitions.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Avoid calling the command and fix test fallout.

https://bugzilla.redhat.com/show_bug.cgi?id=1673320Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

QEMU plans to deprecate 'query-events' as it's non-extensible. Events
are also described by 'query-qmp-schema' so we can use that one instead.

This patch adds detection of events to
virQEMUCapsProbeQMPSchemaCapabilities using the same structure declaring
them for the old approach (virQEMUCapsEvents). This is possible as the
name is the same in the QMP schema and our detector supports that
trivially.

For any complex queries virQEMUCapsQMPSchemaQueries can be used in the
future.

For now we still call 'query-events' and discard the result so that it's
obvious that the tests pass. This will be cleaned up later.

https://bugzilla.redhat.com/show_bug.cgi?id=1673320Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The event was added by qemu commit 6f382ed226f3 released in v1.1.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

DEVICE_DELETED was added in qemu commit 0402a5d65ec00 which was released
in v1.5.0.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The event was added by qemu commit 2fdd16e239c2a2 released in v1.3.0.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Remove the uneeded attribute and return value.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The event was added to qemu by commit 973603a813c5d60 which is contained
in the 1.2.0 release.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Avoid regressions by disallowing the BLOCKDEV capability.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

QEMU accidentally exposed the id of -drive (or same value as disk
serial, if provided) in one of the identifiers visible from the guest.

To avoid regression in case when -blockdev will be used we need to
always specify it ourselves.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The property allows to control the guest-visible content of the vendor
specific designator of the 'Device Identification' page of a SCSI
device's VPD (vital product data).

QEMU was leaking the id string of -drive as the value if the 'serial' of
the disk was not specified. Switching to -blockdev would impose an ABI
change.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

For SCSI, IDE, and AHCI cdroms the appropriate device types which select
the correct media are used. In qemu there's one other code path that
looks at -drive media=cdrom in the XEN pv code. Thankfully we don't
support it with qemu (see qemuBuildDiskDeviceStr). All other devices
ignore it as the comment states, thus we can drop that code.

The test fallout is expectedly only in the test added for uncommon cdrom
types.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Attempting to create an empty virtio-blk drive results into:
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xc,drive=drive-virtio-disk1,id=virtio-disk1: Device needs media, but drive is empty

Attempting to eject media from virtio-blk based drive results into:
error: internal error: unable to execute QEMU command 'eject': Device 'drive-virtio-disk0' is not removable

Forbid configurations where users would attempt to use cdroms in virtio
bus.

Fix few wrong examples which are not really relevant to the tested code.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Cast disk->bus to proper type and add missing values to the enum so it's
more obvious what types are supported.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The split of ide-disk into the two separate devices was introduced by
qemu commit 1f56e32a7f4b3 released in qemu v0.15.

Note that when compared to the previous commit which made sure that no
disk related tests were touched, in this case it's not as careful.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The split of scsi-disk into the two separate devices was introduced by
qemu commit b443ae67 released in qemu v0.15.

All changes to test files are not really related to disk testing thanks
to previous refactors.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Since commit a4cda054 we are using 'ide-hd' and 'ide-cd' instead of
'ide-drive'. We also should probe capabilities for 'ide-hd' instead of
'ide-drive'. It is safe to do as 'ide-drive' is the common denominator
of both 'ide-hd' and 'ide-cd' so all the properties were common.

For now the test data are modified by just changing the appropriate type
when probing for caps.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Since commit 02e8d0cf we are using 'scsi-hd' and 'scsi-cd' instead of
'scsi-disk'. We also should probe capabilities for 'scsi-hd' instead of
'scsi-disk'. It is safe to do as 'scsi-disk' is the common denominator
of both 'scsi-hd' and 'scsi-cd' so all the properties were common.

For now the test data are modified by just changing the appropriate type
when probing for caps.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

This flag tells virDomainMigrateSetMaxSpeed and
virDomainMigrateGetMaxSpeed APIs to work on post-copy migration
bandwidth.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This typed parameter for virDomainMigrate3 and virDomainMigrateToURI3
APIs may be used for setting maximum post-copy migration bandwidth.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

So far migration parameters were changed only at the beginning of
migration mostly via an automatic translation from flags and typed
parameters. We need to export a few more functions to support APIs which
may set migration parameters while migration is already running.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Let's make the code flow easier to follow and get rid of the ugly endjob
label inside if branch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Some migration parameters supported by libvirt may use units that differ
from the units used by QEMU for the corresponding parameters. For
example, libvirt defines migration bandwidth in MiB/s while QEMU expects
B/s. Let's add a unit field to qemuMigrationParamsTPMapItem for
automatic conversion when translating between libvirt's migration typed
parameters and QEMU's migration paramteres.

This patch is a preparation for future parameters as the existing
VIR_MIGRATE_PARAM_BANDWIDTH parameter is set using "migrate_set_speed"
QMP command rather than "migrate-set-parameters" for backward
compatibility.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

qemuDomainBlockPivot and qemuDomainBlockJobAbort need the job name for
cancelling or pivoting but were generating it locally instead of
accessing the existing copy in the job data structure.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The writing to an image actually starts when the copy job is initiated,
so checking this at the time of the pivot operation is too late.

Move the check to qemuDomainBlockCopyCommon. Note that modern qemu would
have prevented two writers with qcow2 so the slim possibility of a job
started with libvirtd without this patch missing the check is not really
worth worrying about.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

For copy and active commit jobs we record the state of the mirror so
that we can recover. The status XML was not saved in case of
qemuDomainBlockPivot due to an oversight.

Save the XML always when invoking qemuDomainBlockJobAbort even if
the job is not currently tracking any state. This will change later and
also this is not a particularly hot code path.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The checks and error messages are mostly the same across
all virtio-input devices, so we can avoid having multiple
copies of the same code.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It will not work. This breaks qemu capabilities probing as a user.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

For normal starts (no incoming migration) the refresh of the QEMU
state must be done before the VCPUs getting started since otherwise
there might be a race condition between a possible shutdown of the
guest OS and the QEMU monitor queries.

This fixes "qemu: migration: Refresh device information after
transferring state" (93db7eea).
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

If a domain has a disk that is type='network' we require specific
cache mode to allow migration with it (either 'directsync' or
'none'). This doesn't make much sense since network disks are
supposed to be safe to migrate by default.

At the same time, we should be checking for the actual source
type, not apparent type set in the domain XML.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Storage pools might want to specify format of the image when translating
the volume thus we can't add any default format when parsing the XML.

Add a explicit format when starting the VM and format is not present
neither by user specifying it nor by the storage pool translation
function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Post parse callback adds the 'raw' type only for local files. Remote
files can also have backing store (even local) so we should do this also
for network backed storage.

Note that virStorageFileGetMetadata always considers files with no type
as raw so we will not accidentally traverse the backing chain and allow
unexpected files being labelled with svirt labels.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In commit f80eae8c I was too agresive in removing properties of
-drive for empty drives. It turns out that qemu actually persists the
state of 'readonly' and the throttling information even for the empty
drive.

Removing 'readonly' thus made qemu open any subsequent images added via
the 'change' command as RW which was forbidden by selinux thanks to the
restrictive sVirt label for readonly media.

Fix this by formating the property again and bump the tests and leave a
note detailing why the rest of the properties needs to be skipped.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Missing semicolon at the end of macros can confuse some analyzers
(like cppcheck <filename>). VIR_ONCE_GLOBAL_INIT is almost
exclusively called without an ending semicolon, but let's
standardize on using one like the other macros.

Add a dummy struct definition at the end of the macro, so
the compiler will require callers to add a semicolon.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>