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>
The attribute is used (and formatted) as virTristateBool() and even in
schema defined as virYesNo, so the values are supposed to be `yes` and
`no`.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update the replies and xml files for QEMU 9.2.0 on s390x based on
the released QEMU tag v9.2.0 with commit Id
ae35f033b874c627d81d51070187fbf55f0bf1a7.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.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>
Again, trivial. Just copy what is done for kernel and initrd.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
If UEFI shim is specified in domain XML but QEMU is too old, then
report an error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
In its commit v9.2.0-323-ga5bd044b15 QEMU introduced another
command line option: -shim. It's used to load kernel. Track
presence of it via QEMU_CAPS_MACHINE_SHIM.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
For secure boot environments where <loader/> is signed, it may be
unfeasible to keep the binary up to date (esp. when revoking
certificates contained within). To address that, QEMU introduced
'-shim' cmd line option which side loads another UEFI binary
which can then contain new certification authorities or list of
revocations. Expose it as <shim/> element that's nested under
<os/>, just like kernel and initrd are.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Notable changes:
- 'uefi-vars-x64', 'uefi-vars-sysbus' qom type added
- 'YongFeng-v1-x86_64-cpu' added
- 'accel' qom type removed
- 'addr' field of devices changed type to 'str'
- 'vfio-pci' gained experimental feature 'x-migration-multifd-transfer'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As now no supported qemu version supports the 'sheepdog' protocol drop
the code for configuring the blockdev layer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The riscv64 qemu-8.0 data were not updated to the release version. Drop
them instead of trying to do archaeology.
They are not used in any 'qemuxmlconftest' case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The aarch-64 qemu-7.0 data were not updated to the release version. Drop
them instead of trying to do archaeology.
They are not used in any 'qemuxmlconftest' case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We'll be bumping to qemu-6.2 as minimum and the aarch64 qemu-6.2 data
were not updated to the release version. Drop them instead of trying to
do archaeology.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'caps_7.0.0_aarch64+hvf' caps dump is fake; obtained from copying
and doctoring the 'caps_7.0.0_aarch64' file (see commit 12aedb414578d3 )
Remove it now that it was superseded by a dump obtained from a proper
hvf-enabled host.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The data is collected from an MacOS host with latest released qemu from
homebrew.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will bump minimum qemu version to 6.2 so we need to
purge old tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will bump minimum qemu version to 6.2 so we need to
purge old tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will bump minimum qemu version to 6.2 so we need to
purge old tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In upcoming patches we'll update minimum supported qemu version to
qemu-6.2 which no longer supports 'sheepdog'. This was the only
hypervisor driver that supported it.
Reject any config containing sheepdog disks when validating the XML,
remove the positive test cases in qemu and replace them by a negative
test case. This will still excercise the XML schema, but will prepare
for removal of the internal code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This function return value is invariant since 1022e0ee, so change
its type and remove all dependent checks.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Reported-by: Alexander Rudyuk <a.rudyuk@fobos-nt.ru>
Signed-off-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Use the new virXMLFormatDirect in order to remove usage of
virXMLFormatInternal.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This can be used to format XML where the element has direct value
instead of any subelement. For example:
<maxMemory slots='16' unit='KiB'>1524288</maxMemory>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This was reported on virt-manager issue tracker as it was possible to
provide `listen` attribute with properly escaped characters but libvirt
would format XML without escaping it.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now we are able to move the rest into virDomainGraphicsDefFormatVNC
without breaking order of elements in the resulting XML.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now we are able to move the rest into virDomainGraphicsDefFormatSpice
without breaking order of elements in the resulting XML.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Daniel P. Berrangé
Pavel Hrdina
Michal Privoznik
Martin Kletzander
Shalini Chellathurai Saroja
Jiri Denemark
Praveen K PaladuguandSmit Gardhariya
Peter Krempa
Alexander Kuznetsov
Nicolás Gal