All supported qemu versions now support this. Retire the capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The support for incremental backup (not the backup api itself) was gated
on support for migrating bitmaps. As the ability to migrate bitmaps was
added in qemu-6.0 we can now assume that all supported qemu versions
support incremental backup.
Remove the interlocking.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported qemus have this and we already deleted alternate code.
Retire the feature flag.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu supports the @allow-write-only-overlay feature since qemu-5.0.
Remove the alternate code paths.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'blockdev-reopen' is supported since qemu-6.1. Since we now don't have
any code using this capability we can retire it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'blockdev-reopen' is supported since qemu-6.1, thus we can now remove
the interlocks.
Document the change to 'mirror' as this patch removes the last clue why
we overwrite the mirror's readonly state to false unconditionally.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability is no longer used as all qemus already support the
feature.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The flat mode of 'query-named-block-nodes' is supported since qemu-5.0.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we dropped support for old qemus which didn't support JSON
props for -object we can retire the capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It was used to convert JSON arrays in legacy -object commandline
conversion. Since we now exclusively use JSON with -object, this
infrastructure is no longer needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The QAPIfication of objects removed the extra wrapper object which we
were adding in the monitor code to simplify the other callers.
Now that we support only qemus which don't require this we can drop the
support code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'-object' was qapified (meaning it supports JSON props) in qemu-6.0,
thus now that we require qemu-6.2 we can drop the compatibility code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability always exists in qemu and is no longer checked.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Bumping minimum version of qemu to 6.2 means that the '-compat' option
is now always supported.
As we were unable to detect it in any other way we based this capability
on QEMU_CAPS_OBJECT_JSON.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virXMLNodeGetSubelementList always returns a non-NULL pointers thus we
should check the length instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The returned value is always non-NULL. Callers need to check the length
of the returned array instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The file used intermixed style. Convert the last outliers to the new
formatting style.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The checks in qemuProcessStartWarnShmem are no longer current. Since
previous patch made it fatal for vhost-user interfaces to be configured
without shared memory this warning code can be deleted.
Resolves: https://issues.redhat.com/browse/RHEL-80533
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently we produce only a warning into the log if a non-passt
vhost-user interface is configured with shared memory.
Since we do make it fatal with all other vhost-user types, fix the check
to trigger also for normal-vhost-user interfaces.
Since passt-based vhost-user interfaces are checked separately the check
will no longer be required.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If 'vm->def->sec->sectype' would be invalid; which is currently not
possible; we'd not unlock the domain object. Fix the logic even when the
bug currently can't happen.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Explain that the 11.2.0 release dates are mostly reflecting when the
constant was first added, not when the key was introduced.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Give an overview of how arrays are handled and represented in
the typed parameters returned by the guest stats API.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the domain stats data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the domain stats
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Explain that the 11.2.0 release dates are mostly reflecting when the
constant was first added, not when the key was introduced.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Give an overview of how arrays are handled and represented in
the typed parameters returned by the guest info API.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Contrary to most APIs returning typed parameters, there are no constants
defined for the guest info data keys. This is was because many of the
keys needs to be dynamically constructed using one or more array index
values.
It is possible to define constants while still supporting dynamic
array indexes by simply defining the prefixes and suffixes as constants.
The consuming code can then combine the constants with array index
value.
With this approach, it is practical to add constants for the guest info
API keys.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Before this patch the code would start the revert process by destroying
the VM and preparing to revert where it would fail with following error:
error: unsupported configuration: source for disk 'sdb' is not a regular file; refusing to generate external snapshot name
and leaving user with offline VM even if it was running.
Make the check before we start the revert process to not destroy VMs.
Resolves: https://issues.redhat.com/browse/RHEL-30971
Resolves: https://issues.redhat.com/browse/RHEL-79928
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The point of virSecurityManagerRestoreAllLabel() function is to
restore ALL labels and be tolerant to possible errors, i.e.
continue restoring seclabels and NOT return early.
Well, in two implementations of this internal API this type of
problem was found:
1) virSecurityDACRestoreAllLabel() returned early if
virSecurityDACRestoreGraphicsLabel() failed, or when
def->sec->sectype equals to an impossible value.
2) virSecuritySELinuxRestoreAllLabel() returned early if
virSecuritySELinuxRestoreMemoryLabel() failed.
Fix all three places.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
With a specific combination of compiler options gcc reported the
following bogus warning (I added a context to it to make the issue
visible):
../src/esx/esx_vi.c: In function ‘esxVI_LookupHostScsiTopologyLunListByTargetName’:
../src/esx/esx_vi.c:4674:32: error: potential null pointer dereference [-Werror=null-dereference]
4671 | if (!found || !hostScsiTopologyTarget)
4672 | goto cleanup;
4673 |
4674 | if (!hostScsiTopologyTarget->lun) {
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~
Most likely this is caused by found and hostScsiTopologyTarget doing
essentially the same thing as found is true if and only if
hostScsiTopologyTarget is non-NULL. The found variable is completely
redundant. Removing it would be enough, but I decided to make the code a
little bit easier to read by not using the iterator variable directly.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Enable SEV-SNP support for ch guests.
Co-Authored-by: Smit Gardhariya <sgardhariya@microsoft.com>
Signed-off-by: Praveen K Paladugu <praveenkpaladugu@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
