This new "post-copy failed" reason for the running state will be used on
the destination host when post-copy migration fails while the domain is
already running there.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
A few commits ago new APIs were introduced (virDomainSaveParams()
and virDomainRestoreParams()) and with them new typed parameters:
VIR_SAVE_PARAM_FILE and VIR_SAVE_PARAM_DXML. But their name does
not suggest they apply to either of the APIs nor that they are
intended for domain related APIs. Switch to
VIR_DOMAIN_SAVE_PARAM prefix to make it obvious.
It's true we already have VIR_DOMAIN_SAVE_* symbols which are
part of virDomainSaveRestoreFlags enum, therefore stick also with
'_PARAM_ ' part of the name to differentiate the two.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
add new API in order to be able to extend parameters to the domain
restore operation. We will use it to fit the existing arguments of
VirDomainRestoreFlags for now.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
create an alternative to virDomainSaveFlags that is more
extendible via parameters.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It allows libvirt to provide the value of cpu0-id retuned by the Qemu QMP
command query-sev-capabilities as implemented by the Qemu Patch [1] which
is merged to Qemu master branch and should be available with Qemu 7.1.
This is used to get the signed Chip Endorsement Key (CEK) of the CPU of AMD
system from AMD's Key Distribution Service (KDS).
Similar to cbitpos, reducedPhysBits, maxGuests & maxESGuests;
the value of cpu0-id is also provided using 'virsh domcapability'.
[1] https://lore.kernel.org/all/20220228093014.882288-1-dovmurik@linux.ibm.com/
Signed-off-by: Niteesh Dubey <niteesh@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It belongs to the comment for VIR_DOMAIN_AFFECT_CONFIG, not to
the unrelated one immediately after it.
Fixes: 807cdbf759
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given function was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given function was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given typedef was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given macro was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given enum value was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given enum value was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Follow up patch will add Since metadata to enum values of
virStorageVolWipeAlgorithm.
This patch is necessary to avoid breaking the build with
syntax-check.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
scripts/apibuild.py does not handle well enum's with comments between
values. The outcome depends on whether the enum value has its own
docstring or not and if there is spaces between the enum values or
not.
This commit removes some generic comments that I have spotted.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There should be no empty lines between a docstring comment and
the symbol it documents.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There should be no empty lines between the Since tag in a
docstring comment and the end marker.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The API xml description file generator doesn't properly handle cases
when there's either a single comment or mixed use of pre- and post-
comments explaining the values.
Modify the comments to avoid the problem and also append version
information for the exposed values.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Similarly to previous commits but with the targeting libvirt-common
in a batch.
Either create or append to existing docstring, the version (git tag)
that a given typedef, enum value, macro or function was introduced
in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given function was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given typedef was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given typedef was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given macro was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given enum value was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
virConnectAuthPtrDefault is the only variable that we export and
with the documentation being at the C file, it makes harder to find
it.
With this patch, the documentation of this variable can be found by
those who look at the header file for guidance plus, it will also be
included in the XML API, as the followup patch will fix apibuild.py
to store what is documented in the header file for this variable.
Note that the apibuild, does not do the same with .c files. It'd
require adding it for (parsing) recursion, similar to what is done
for functions. Considering the pros/cons, seems more reasonable to
move the docstring to the header file instead.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
scripts/apibuild.py does not handle well enum's with comments
between values. The outcome depends on whether the enum value has
its own docstring or not and if there is spaces between the enum
values or not.
Either way, virConnectListAllNodeDeviceFlags documentation is
explicit that this enum is about filtering node devices. We can move
the information that it is either by "capability" or "active" state
to the block of comment above.
Using git diff --word-diff to show the fixed ouput xml (redacted).
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_ACTIVE' ... [-info='Inactive-]{+info='Active+} devices'/>
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_AP_CARD' ... [-info='vDPA-]{+info='s390 AP Card+} device'/>
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_AP_MATRIX' ... [-Queue'/>-]{+Matrix'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_AP_QUEUE' ... [-Card device'/>-]{+Queue'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_CCW_DEV' ... [-info='Mediated-]{+info='CCW+} device'/>
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_CSS_DEV' ... [-info='CCW-]{+info='CSS+} device'/>
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_DRM' ... [-info='Capable of scsi_generic'/>-]{+info='DRM device'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_FC_HOST' ... [-info='Storage device'/>-]{+info='FC Host Bus Adapter'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_MDEV' ... [-info='Capable of mediated devices'/>-]{+info='Mediated device'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_MDEV_TYPES' ... [-info='DRM device'/>-]{+info='Capable of mediated devices'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_NET' ... [-info='USB interface'/>-]{+info='Network device'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_PCI_DEV' ... [-info='System capability'/>-]{+info='PCI device'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_SCSI' ... [-Target'/>-]{+device'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_SCSI_GENERIC' ... [-vport'/>-]{+scsi_generic'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_SCSI_HOST' ... [-info='Network device'/>-]{+info='SCSI Host Bus Adapter'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_SCSI_TARGET' ... [-Host Bus Adapter'/>-]{+Target'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_STORAGE' ... [-info='SCSI-]{+info='Storage+} device'/>
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_SYSTEM' ... [-info='filter the devices by cap type'/>-]{+info='System capability'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_USB_DEV' ... [-info='PCI-]{+info='USB+} device'/>
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_USB_INTERFACE' ... [-device'/>-]{+interface'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_VDPA' ... [-info='CSS-]{+info='vDPA+} device'/>
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_VPD' ... [-info='s390 AP Matrix'/>-]{+info='Device with VPD'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_CAP_VPORTS' ... [-info='FC Host Bus Adapter'/>-]{+info='Capable of vport'/>+}
<enum name='VIR_CONNECT_LIST_NODE_DEVICES_INACTIVE' ... [-info='Device with VPD filter the devices by active state'/>-]{+info='Inactive devices'/>+}
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
If this flag is set on calling virDomainDestroyFlags flags then remove
per domain logs if possible.
This can be used by libguestfs to delete logs for temporary domain.
Otherwise such logs will stay wasting disk resources.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This API has the same semantics as 'virDomainQemuMonitorCommand' but
accepts file descriptors which are then forwarded to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce virDomainDirtyRateCalcFlags to get ready for
adding mode parameter to qemuDomainStartDirtyRateCalc.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When starting a guest with pflash based firmware, we will initialize
NVRAM from a template if it does not already exist. In theory if the
firmware code file is updated, the existing NVRAM variables should
continue to work correctly. It is inevitable that this could break
accidentally one day. Or a bug in the firmware might corrupt the
NVRAM storage. Or user might make bad changes to the settings that
prevent booting. Or the user might have re-configured the XML to
point to a different firmware file incompatible with the current
variables.
In all these cases it would be useful to delete the existing NVRAM
and initialize it from the pristine template.
To support this introduce a VIR_DOMAIN_START_RESET_NVRAM constant
for use with virDomainCreate / virDomainCreateXML, along with
VIR_DOMAIN_SAVE_RESET_NVRAM for use with virDomainRestore and
VIR_DOMAIN_SNAPSHOT_REVERT_RESET_NVRAM for use with
virDomainSnapshotRevert.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
1. s/LifeCycle/Lifecycle/
2. s/virConnectDomainEventTrayChangeReason/virDomainEventTrayChangeReason/
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This API allows setting a launch secret within a guests's memory. The
launch secret is created by the guest owner after retrieving and
verifying the launch measurement with virDomainGetLaunchSecurityInfo.
The API uses virTypedParameter for input, allowing it to be expanded
to support other confidential computing technologies. In the case of
SEV, a basic guest launch workflow is described in the SEV API spec
in section "1.3.1 Launch"
https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are limits on the number of SEV/SEV-ES guests that can
be run on machines, which may be influenced by firmware
settings. This is important to expose to users.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Three more parameters are required in order that clients can
perform a launch attestation on the SEV guest.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Non-shared storage migration of guests which are disk I/O intensive and
have fast local storage may actually never converge if the guest happens
to dirty the disk faster than it can be copied.
This patch introduces a new flag
'VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES' which will instruct
hypervisors to synchronize local I/O writes with the writes to remote
storage used for migration so that the guest can't overwhelm the
migration. This comes at a cost of decreased local I/O performance for
guests which behave well on average.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Using whitespace to align the '=' and values doesn't make sense for the
virDomainMigrateFlags enum as the visual block is interrupted by
comments.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In cases when the destination storage is slower than the normal VM
storage and the VM does intensive I/O to the disk a block copy job may
never converge.
Switching it to synchronous mode will ensure that all writes done by the
guest are propagated to the destination at the cost of slowing down I/O
of the guest to the synchronous speed.
This patch adds the new API flag and implements virsh support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
* XML serialization and deserialization of PCI VPD;
* PCI VPD capability flags added and used in relevant places;
* XML to XML tests for the added capability.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
This patch makes the descriptions of virStoragePoolCreateFlags annotate to the
correct flag in the generated HTML file.
Signed-off-by: Robin Lee <cheeselee@fedoraproject.org>
As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as 'requested
size'. It almost certainly will be when sizing the memory up, but
it might not be when sizing the memory down - the guest kernel
might be unable to free some blocks.
This current size is reported in the domain XML as an output
element only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
