IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The condition
WITH_LINUX_KVM_H && (defined(__linux__) || defined(__FreeBSD__))
is redundant. If the meson check for linux/kvm.h succeeded, we
must be on a Linux host and cannot be on a FreeBSD host. Remove
these redundant OS conditions from the MSR code to stop misleading
readers.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In the upcoming qemu-10.2 release the 'virt-4.2' machine type will be
removed.
To preserve the spirit of the test pin the existing test to qemu-10.0
and add a new version using 'virt-10.0' machine type.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In the upcoming qemu-10.2 release the 'virt-4.0' machine type will be
removed. Update all existing tests which use it to 'virt-10.0' which is
currently present in our caps dump.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Notable changes:
- New 'postcopy-device' migration state
- New 'exit-with-parent' option
- Features 'guest_tunnel_csum', 'host_tunnel', 'host_tunnel_csum',
'guest_tunnel' of 'virtio-net-pci' are now enabled by default
- 'extended-tseg-mbytes' is now 64 for 'mch' device
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Document the new VNC's 'wait' attribute in formatdomain.rst and
drvbhyve.rst.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
On Fedora 43 and newer the 'fuse-zfs' package was removed. Commit
bd30147e74 added an 'Obsoletes' directive so that the storage driver
core package will update properly but hardcoded the obsoleted version
as 11.4 (when the change was comitted) similarly to the old sheepdog/rbd
packages and disabled the build.
Now it is still possible to obtain ZFS support from other means and it
may be useful for users to have libvirt's ZFS backend. This patch thus:
- re-enables build of 'libvirt-daemon-driver-storage-zfs' on Fedora
- removes 'libvirt-daemon-driver-storage-zfs' as 'Requires dependency
from 'daemon-driver-storage' meta-package on Fedora 43 and newer
- removes dependancy on '/sbin/zpool' and '/sbin/zfs' on Fedora 43
and newer
With this the package still is built and installable but will require
users to get their ZFS support installed somehow.
Fixes: bd30147e74
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add the 'dpofua' setting in the XML and for the qemu driver.
DPO - Disable Page Out and FUA - Force Unit Access are two features
implemented by SCSI disks (either both together or neither of them)
which influence how caching is handled. QEMU provides a good default
but in certain specific occasions changing the default may have
performance benefits.
Add support for setting them via the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Allow other sub-projects using the XSL template without modification.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While our main page uses same argument for both to ensure that the
linking works also when browsed locally sub-projects such as
libvirt-wiki and libvirt-security-notice will want to pull 'site.xsl' as
is into their build assets. Pass both arguments via the build system so
that we don't have to carry distinct instances.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our other sub-projects such as the libvirt-wiki and soon also the
libvirt-security-notices will use the same CSS via asset import script.
Move any specifics into 'local.css' which will be defined by the
sub-projects so that 'main.css' can be imported directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our main page mentions security notices which we host at
https://security.libvirt.org but links to them only from the security
process page. Since we already have the wording there, turn it directly
into a link.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Implement the support for VIR_DOMAIN_BACKUP_BEGIN_PRESERVE_SHUTDOWN_DOMAIN
which will keep the qemu process around while the backup is still
running.
The above is achieved by avoiding killing the qemu process in the
shutdown qemu monitor event handlers. Instead 'system_reset' QMP command
is issued and the domain object is transitioned into _PAUSED state in
sync with what qemu does.
Now once the backup job finishes (or is cancelled e.g. for pull mode
backups) the backup job termination code re-asseses if the qemu process
needs to be killed or the VM was re-started by un-pausing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This flag will instruct the hypervisor driver to keep the VM around
while the backup is running if the guest OS decides to shut down, so
that the backup can be finished.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will introduce the possibility for the domain to be
kept paused after the guest OS shuts itself down. It'll allow jobs
such as backup to finish as e.g. in the qemu driver it requires the qemu
process.
Add an the appropriate reason for the VIR_DOMAIN_EVENT_SUSPENDED
lifecycle event.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the notification to the backup job after finishing the cleanup of
the current block job the backup operation consists of.
Currently the termination of the blockjob would e.g. delete the scratch
files before they are detached from qemu.
In later patches the termination of the backup job may cause the qemu
process to be killed (if the guest OS shut down but the qemu process
was being kept alive to finish the backup) which would cause errors in
the monitor commands for dismissing the block job.
Since the NBD server still needs to be terminated first as otherwise
the scratch files can't be unplugged from qemu we need to split the
operation into two. First the NBD server is terminated, then the
current block job is finalized and then the backup job is notified.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When notifying the backup code about termination of the block job which
is part of a backup operation the code attempts to terminate the NBD
server. This is done for every blockjob so could cause us to attempt to
terminate the NBD server multiple times which doesn't cause problems but
generates spurious errors.
Add a flag that the NBD server was stopped and do it just once. Don't
bother storing the flag in the status XML as it's just for the shutdown
phase.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'qemuProcessShutdownOrReboot' may or may not kill the VM. In
'qemuProcessReconnect' if we decided that the VM was in a state
requiring 'qemuProcessShutdownOrReboot' to be called we'd stop the
reconnection unconditionally.
Now if the VM ought to undergo a fake reboot we really need to reconnect
to the process because the process will be kept around for much longer.
Make qemuProcessShutdownOrReboot return whether it killed the VM and
continue the reconnection if it didn't.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The VIR_JOB_MODIFY_MIGRATION_SAFE is supposed to be a subset of _MODIFY
jobs which are allowed during migration.
Now with async jobs which allow VIR_JOB_MODIFY (namely the backup job)
it shouldn't be required to explicitly mention
VIR_JOB_MODIFY_MIGRATION_SAFE since we already allow everything.
Adjust the logic in virDomainNestedJobAllowed to accept
VIR_JOB_MODIFY_MIGRATION_SAFE if VIR_JOB_MODIFY is allowed so that other
places can simply allow the latter.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our preference is to unconditionally report all features known
to libvirt code, rather than pre-filter them by architecture.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently domain capabilities will only ever report
<tdx supported='yes'/>
so it is not possible to determine whether libvirt itself is
new enough to have TDX support or not, vs the host OS lacking
it.
For SEV and s390 prot-virt, the capability is always reported
whether supported or not, so do likewise for TDX, so other
x86 hosts get:
<tdx supported='no'/>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Querying existence of the 'tdx-guest' type merely tells us whether
QEMU has been compiled with TDX support, not whether it is usable
on the host. Thus QEMU was incorrectly reporting
<tdx supported='yes'/>
...
<launchSecurity supported='yes'>
<enum name='sectype'>
<value>tdx</value>
</enum>
</launchSecurity>
on every platform with new enough QEMU.
Unfortunately an earlier patch for a 'query-tdx-capabilities' QMP
command in QEMU was dropped, so there is no way to ask QEMU whether
it can launch a TDX guest. Libvirt must directly query the KVM
device and ask for supported VM types.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This describes the new index based certificate naming scheme, and
how to create & deploy certificates for post-quantum cryptography.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In addition to servercert.pem / serverkey.pem, we now also support
loading servercert{N}.pem / serverkey{N}.pem, for values of {N}
between 0 and 3 inclusive.
If servercert0.pem is provided, then using servercert.pem becomes
optional. The first missing index terminates the loading process.
eg if servercert1.pem is NOT present, then it will NOT attempt to
look for servercert2.pem / servercert3.pem.
This also applies to clientcert.pem / clientkey.pem.
This facilitates the transition to post-quantum cryptography by
allowing loading of certificates with different algorithms,
eg traditional RSA based cert, and optional ECC based cert or
MLDSA based cert for PQC.
The use of CA cert files is unchanged with only a single cacert.pem
loaded. WHen multiple CAs are needed they must be concatenated in
the single cacert.pem file.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The three different APIs for locating credentials differ only in
what directories they search and their policy for missing files.
Their code can be collapsed onto a single helper method. This
will greatly facilitate the subsequent patch that expands the
logic to locate many certificate files.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A future patch will require fule access checks to be done
as part of locating the certificate files, as we will have
the ability to load many more files, most of which will be
optional.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virNetTLSConfigCustomCreds will always set the cert paths
to non-NULL strings. This in turn means that the later call to
virNetTLSConfigSystemCreds will be a no-op aside from duplicating
log information. Refactor the conditions so that the call to
find system credentials is skipped when using custom credentials.
While this patch could have just done an early "return 0" after
the virNetTLSConfigCustomCreds call, an "} else {" branch is
instead added, since this will facilitate a later patch in this
series which prefers a common return path.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 'cert_file' and 'key_file' parameters in libvirtd.conf only
permit a single cert/key. To support hybrid deployments for PQC,
we need to be able to request multiple certs/keys. This involves
new 'cert_files' and 'key_files' config parameters that accept a
list of filenames. The new parameters are mutually exclusive with
the old parameters.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In the transition to Post-Quantum Cryptography, it will often be
desirable to load multiple sets of certificates, some with RSA/ECC
and some with MLDSA. This extends the TLS context code to support
the loading of many certs, passed as a NULL terminated array.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Future patches will make it possible to load multiple certificate
files. This prepares the sanity checking code to support that by
taking a NUL terminated array of cert filenames.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The callers are all passing in a 'bool' value, and this type
should be maintained rather than cast to 'int' and then
inpreted as a bool again later.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Rename variable "allowZero" to "allowPortZero" for clarity and update the virtconsole port reservation comment,
as port 0 is reserved for the first virtconsole unless specified.
Signed-off-by: Aaron M. Brown <aaronmbr@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This change fixes an issue with virtio console port assignment on virtio-serial buses.
Currently, when trying to autoassign a virtio console device, the device cannot be
assigned to a port greater than 0 on virtio-serial buses.
You will receive the following error:
`virtio-serial-bus: A port already exists at id 0`
Therefore, the data needs to be passed back into info when allowZero is true.
We should also preserve the controller data when allowZero is true, and
propagate allowZero into virDomainVirtioSerialAddrNextFromController
to get an appropriate startPort.
Fixes: 16db8d2e ("Add functions to track virtio-serial addresses")
Signed-off-by: Aaron M. Brown <aaronmbr@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add test coverage for multiple virtio consoles on a virtio-serial controller.
This test makes sure that multiple virtconsoles get auto-assigned appropriate
port numbers on a virtio-serial-bus.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Aaron M. Brown <aaronmbr@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The main stream I/O functions have a design flaw in that they accept
'size_t' as the input data length, while intending to return the
amount actually processed in an 'int'.
Fortunately all functions explicitly document that less data may be
processed than requested, and with the remote driver data cap we will
never get anywhere near exceeding an 'int' even on 32-bit.
For sanity, however, lets explicitly cap the data size in the public
API to fix the design flaw.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The recent commit:
commit 166be0d48c
Author: Peter Krempa <pkrempa@redhat.com>
AuthorDate: Fri Sep 12 13:32:36 2025 +0200
Commit: Peter Krempa <pkrempa@redhat.com>
CommitDate: Wed Nov 5 14:27:57 2025 +0100
Expose qemu timed block statistics via bulk stats API
had a bit of delay between authoring and merging, such that the
merged version number was outdated.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Create a common `virttype` definition in basictypes.rng and reuse it
to enumerate all virt types. This change eliminates the need to duplicate
virttypes in multiple locations.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Conditionally add /dev/mshv device to acl while launching
hyperv domains.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Qemu with mshv capabilities can launch VIR_DOMAIN_VIRT_HYPERV domains.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This capability indicates if qemu supports mshv as an accelerator. Qemu
with mshv capabilities can launch domains of type VIR_DOMAIN_VIRT_HYPERV.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When updating the guest CPU model and the deprecated_features attribute
is set to on, only enable the features the model can actually enable.
While host-model would normally just enable these features without
intervention (and without the presence of the deprecated_features
attribute), custom models would see no changes to their feature set
without these changes.
This is useful for e.g. testing CPU models.
Fixes: f279ea36 (qemu: process: refactor deprecated features code)
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When performing a static CPU model expansion, the reported list of
deprecated features will reflect the features which are currently
enabled on the CPU model.
Retrieve this subset and store them as static deprecated properties for
the model info, and as host deprecated features in the cache.
Note that this list may exclude items that are shown in the
<deprecatedFeatures> list, as some feature support has been dropped by
hardware (e.g. csske).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The current query of deprecated properties is the result of a full model
expansion. Rename the field to reflect this.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When reworking the vmx2xmltest to call esxParseVMXFileName() from
the ESX driver I also made the test link with the driver
statically. But the function then calls some other functions
which are mocked in vmx2xmlmock. Now, on many systems this works
just fine as the dynamic linker finds the mocked functions first.
But on Fedora 41 and Fedora 42 the dynamic linker resolves the
symbols to those from statically linked library rendering our
mock ineffective.
Just don't link in the esx_lib.
Fixes: f82d30307d
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add Apache CloudStack to the docs/apps.rst file, IaaS section.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Nux <nux@li.nux.ro>
It's already defined by default in systemd:
https://github.com/systemd/systemd/blob/v257.6/sysusers.d/basic.conf.in#L32
Adding it again here in libvirt-qemu.sysusers.conf causes the following
warning by validating it with sd-sysuers:
/usr/lib/sysusers.d/libvirt-qemu.conf:1: Conflict with earlier configuration for group 'kvm' in /usr/lib/sysusers.d/basic.conf:32, ignoring line.
On Fedora/RHEL systemd is built with -Dkvm-gid=36 so there is no change
in the allocated GID on these platforms. Other platforms have the same
facility available to them if they wish to retain a fixed GID.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Achill Gilgenast <achill@achill.org>
Commit 034f02d25c added new test for the
Intel(R) Xeon(R) 6788P cpu model. The test depends on QEMU driver. If
the driver is not available, then skip it. Similarly as in commit
c22b734117.
Signed-off-by: Jaroslav Suchanek <jsuchane@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Since the recent change:
commit f82d30307d
Author: Michal Prívozník <mprivozn@redhat.com>
Date: Fri Nov 14 10:35:14 2025 +0100
vmx2xmltest: Drop custom file name parse function
The VMX parsing uses the esxParseVMXFileName() function in
the ESX library. This is unavailable when the ESX driver is
disabled, so the tests must be skipped too.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since e2bc742fcc we do not
install it on RHEL nor Fedora.
OpenSUSE is also new enough that it disables the installation.
On Debian, sysctl files are only installed as an example.
Remove the option and delete the file.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Provide sample XML and CLI args for the device-pluggable smmuv3
XML schema for virt machine type.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce support for "pciBus" driver attribute for
"smmuv3" IOMMU model. The "pciBus" attribute indicates
the index of the controller that a smmuv3 IOMMU device
is attached to, and differentiates the device-pluggable
arm-smmuv3 model from the virt-machine-associated smmuv3
model.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add support for parsing multiple IOMMU devices from
the VM definition when "smmuv3" is the IOMMU model.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Format qemu arguments for IOMMU devices after
controllers as the multi-SMMUv3 model associates
SMMUv3 devices with hostdevs by plugging them
into the same controller upstream.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Operate on a virPCIDeviceAddress, not virDomainDeviceInfo
so that this can be reused to look for buses that are not
stored in the device info.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve supports the 'wait' option for the VNC device configuration.
When enabled, VM boots only upon a VNC connection.
Sample device configuration looks like this:
-s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Introduce an optional 'wait' attribute for 'VNC'.
When set to 'yes', VM should only boot upon the initiation of a VNC
connection.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
On x86 we can indicate VMX or SVM, while s390x would be SIE, and
PowerPC would be LCPR (Logical Partitioning Control Register).
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If we fail to find either SEV or TDX on x86, we can explicitly
say there is no secure guest support on the platform.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
For AMD, the virt-host-validate 'secure guest' check reports
support for SEV, and there are then further check results
printed for SEV-ES/SEV-SNP which are overly verbose and the
long lines break output alignment.
This uses the new ability to report details with PASS results
to concisely tell the user which out of SEV/SEV-ES/SEV-SNP
are found. Only a single answer is neede, as SEV-SNP implies
SEV & SEV-ES, and SEV-ES implies SEV.
The TDX s390x PROT-VIRT checks also identify themselves.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In a number of virt-host-validte tests we are testing for
at least one out of multiple acceptable features. For
example the 'secure guest' test can be satisfied by
s390x protvirt, or x86 TDX, SEV, SEV-ES, SEV-SNP.
It would be useful to inform the user which one we detected
when the test passes. This introduces virValidatePassDetails
to enable that.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates correctness of the previous fix.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The esxParseVMXFileName() function parses path to a disk image
trying to replace some "known" patterns (e.g. datastore paths).
A simple filename is treated as a path relative to .vmx file. But
disk images (and thus filenames) can be in a subdirectory,
relative to the .vmx file. For instance:
subfolder/disk.vmdk
Adapt our parser to this fact.
Resolves: https://issues.redhat.com/browse/RHEL-122751
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Having a custom file name parsing function in vmx2xml that's
different to the one used in production (esxParseVMXFileName())
might have served us well, but it also defeats the point of
having a unit test. More specifically, if there's a bug in
esxParseVMXFileName() then our unit test would not catch it.
But now that we have vmx2xmlmock the custom parsing function can
be dropped and the test can use the real one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
If we want vmx2xmltest to use actual file name parser that's used
in production (esxParseVMXFileName()) we need a mock to stop it
from doing any HTTP requests and also to return predictable data.
So far, the function can call three functions that do HTTP
requests: esxVI_LookupDatastoreList(),
esxVI_LookupDatastoreHostMount() and
esxVI_LookupDatastoreByName().
Mock all three of them. And since their implementation uses some
other symbols (like allocators or _AppendToList() helpers) we
need to expose these symbols too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This function is going to be mocked soon. Annotate and export it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This function is going to be mocked soon. Annotate and export it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This function is going to be mocked soon. Annotate and export it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
So far, our vmx2xmltest uses a custom .parseFileName callback.
And it kind of makes sense because the one that's used in
production (esxParseVMXFileName()) does some HTTP requests which
we don't want to do in our test suite. But this creates other
sorts of problems and the idea is to have the test ditch custom
parse callback and stick with the production one. But for now,
just expose it. With it, the esxVMX_Data struct is exposed too as
it is passed into the function (via 'opaque' argument).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The esxVI_DateTime_ConvertToCalendarTime() symbol is declared in
esx_vi_types.h header file. Reflect this in the corresponding
.syms file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Since v0.8.0 a watchdog notification is available under event ID
VIR_DOMAIN_EVENT_ID_WATCHDOG, update the documentation to remove the
previous limitation.
Signed-off-by: Massimiliano Minella <massimiliano.minella@se.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
While it may seem that zero detection is pointless for backing chain
layers other than the top one, which is usually the only one gettin
written to, with block operations such as active-layer commit the
non-top layer may become active, in which case the VM wouldn't be
configured in accordance to the XML any more.
Similarly with snapshots a new image is introduced which would not get
zero detection enabled, but next start of the VM would enable it.
Fix this by propagating the zero detection setting for all layers.
This problem partially addresses one of the issues reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120389
Fixes: 8a78f88a1a and a522c3044b (effectively reverts them)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add test cases for all three options 'off'/'on'/'unmap' as well as add
backing store for each image to show how the configuration behaves.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This marks kernel, initrd, dtb, and similar elements with is_shared,
meaning we skip label restore if xattr label remembering is not
enabled or supported (like on qemu:///session).
non-xattr based label restore is subject to race conditions if
multiple VMs are starting and stopping using shared media:
https://issues.redhat.com/browse/RHEL-126945
This converts every case that is using content_context (virt_content_t)
as SetFileLabel time, which is how we are marking content as
readonly. All the shareable cases (marked with file_context) are
already skipping remembering/label restore entirely.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
If set, we will skip fallback label restore attempts, if label
remembering fails or isn't supported.
This is a no-op, as every caller passes in `false` which matches
existing behavior. Next patch will make use of it
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
For shareable/readonly devices, label restore is skipped entirely in
virSecuritySELinuxRestoreSCSILabel. So requesting remember=true here
doesn't accomplish anything
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
virSecuritySELinuxSetSavedStateLabel uses remember=false, but
virSecuritySELinuxRestoreSavedStateLabel uses recall=true.
This doesn't cause problems in practice, just some redundant xattr
calls. But Set and Restore calls should be matched here.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
External inactive snapshots are created by invoking 'qemu-img' which
creates the file. Currently qemu-img creates image with mode 644 based
on default umask as libvirt doesn't set any.
Having a world-readable image is obviously wrong so set the umask to
077 to have the file readable only by the owner.
Resolves: https://bugs.debian.org/1120119
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Utilise the new virDomainDefIDsParseString() for that.
This is one of the more complex ones since there is also a function that
reads relevant metadata from a save image XML. In order _not_ to extract
the parsing out of the function (and make the function basically trivial
and all callers more complex) add a callback to the function which will
be used to check the ACLs.
Fixes: CVE-2025-12748
Reported-by: Святослав Терешин <s.tereshin@fobos-nt.ru>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Utilise the new virDomainDefIDsParseString() for that.
This is one of the more complex ones since there is also a function that
reads relevant metadata from a save image XML. In order not to extract
the parsing out of the function (and make the function basically trivial
and all callers more complex) add a callback to the function which will
be used to check the ACLs. And since this function is called in APIs
that perform ACL checks both with and without flags, add two of them for
good measure.
Fixes: CVE-2025-12748
Reported-by: Святослав Терешин <s.tereshin@fobos-nt.ru>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This function performs only parsing with the underlying
virDomainDefParseIDs() function to get needed metadata for any ACL
checks, but nothing else to avoid extraneous allocations and any
parser-induced DoS over ACL-forbidden connections.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'libxml2' deprecated the 'xmlIndentTreeOutput' thread-local variable as
well as the 'xmlThrDefIndentTreeOutput' function for setting the global
default, which we use in our code for formatting the metadata sub-XML.
'libxml2' also for now doesn't provide a way to set target indentation
level in 'xmlSaveCtxt' which would allow us to use the modern output
APIs, we can't replace our use of 'xmlDumpNode'. (See
https://gitlab.gnome.org/GNOME/libxml2/-/issues/989 )
Since the indentation is enabled by default in libxml2 and our most
commonly used code which calls xmlDumpNode lives in a standalone
process, where we don't override the setting, just removing the override
will result in identical behaviour.
For the use cases which do live in a process we don't fully control and
thus the default could have been overriden, the result would be that the
<metadata> element would be un-indented, but that is still valid XML.
Thus to fix the deprecated use just stop setting 'xmlIndentTreeOutput'.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/816
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
'xmlIndentTreeOutput' is now deprecated by libxml2.
The default value set by libxml2 is '1', and the vbox driver resides
only inside the standalone daemon where the value will not be changed by
us thus there's no observable change in behaviour.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Do not allow to configure queues and queue size for non-NVMe disks.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor bhyveDomainDeviceDefValidate() to use switch/case instead of
series of ifs which makes it easier to follow.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
bhyve supports queue configuration for the NVMe disks:
maxq Max number of queues.
qsz Max elements in each queue.
Map that to the disk driver's "queues" and "queue_size" attributes
respectfully, so:
<driver name='file' type='raw' queues='2' queue_size='256'/>
results in:
-s N:0,nvme,/tmp/disk.img,maxq=2,qsz=256
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, virDomainDiskDefValidate() allows to configure disks' number
of queues and queue size for virtio disks only. However, the bhyve
driver allows to configure these for the NVMe disks, so make this
check driver-specific.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a section with guest-specific notes. Start with LPC slot address
information for the Windows guests.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When linking to the bhyve(8) manual page, do not set manpath
to a specific FreeBSD version so the latest actual version
is displayed.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In RHEL and Fedora, the built-in GNUTLS default priority is changed
from "NORMAL" to "@SYSTEM", but because libvirt sets an explicit
policy with gnutls we don't honour that. Instead we force "NORMAL"
unless the 'tls_priority' meson option is changed.
In RPM builds, meanwhile, we ask for "@LIBVIRT,SYSTEM" to make it
look for a libvirt specific profile first, falling back to "@SYSTEM"
This changes the meson option to default to "@LIBVIRT,SYSTEM" if the
crypto-policies config is present on the local machine and the meson
option -Dsystem=true is given.
This gives developers more appropriate default behaviour, matching
that seen in package builds.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Firstly, there's no need to list header files in
ch_driver_sources (we don't do that anywhere else, and meson is
smart enough to figure them out). And secondly, the list of
source file is not sorted which means new source files are added
in random order.
Thus, drop header files from the list and sort it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Assigning device should happen from ch_hotplug.c (just like it's
done for disks currently) not in ch_process.c. Move alias
assignment out of chProcessAddNetworkDevice(). And while at it,
mimic what's done with disks and have net hotplug handling done
from a function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Libvirt's philosophy is that for a running domain there are two
(in general distinct) definitions: live definition (reflects the
running state) and inactive definition (used to seed the live
definition when domain is being created). That's why we have
VIR_DOMAIN_AFFECT_LIVE and VIR_DOMAIN_AFFECT_CONFIG flags to APIs
that modify domain definitions.
Well, the CH driver doesn't do this distinction. Fix this by
making the domain definition transient when it's being created.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The chDomainGetXMLDesc() function claims to support
VIR_DOMAIN_XML_INACTIVE to obtain the persistent definition of a
running domain (in its call to virCheckFlags()) but in fact, it's
always passing vm->def to virDomainDefFormat().
So far, there's no harm done because CH driver never sets domain
def as transient. But that'll change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The 'payload' variable inside of chProcessAddNetworkDevice() is
reused and thus the memory it points to just before its
repurpose is not freed. Avoid reusing g_autofree variables.
128 bytes in 1 blocks are definitely lost in loss record 1,828 of 2,026
at 0x491A120: realloc (vg_replace_malloc.c:1801)
by 0x4FEC251: g_realloc (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x500BB7E: g_string_expand (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x500BBF0: g_string_sized_new (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x4A114C0: virBufferInitialize (virbuffer.c:121)
by 0x4A11890: virBufferAdd (virbuffer.c:160)
by 0x4A67344: virJSONValueToBuffer (virjson.c:1562)
by 0x4A673DB: virJSONValueToString (virjson.c:1599)
by 0xBC878AB: virCHMonitorBuildNetJson (ch_monitor.c:466)
by 0xBC8D4A9: chProcessAddNetworkDevice (ch_process.c:688)
by 0xBC8FCE2: chDomainAttachDeviceLive (ch_hotplug.c:78)
by 0xBC900CA: chDomainAttachDeviceLiveAndUpdateConfig (ch_hotplug.c:174)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Domain capabilities XML is formatted (mostly) using
FORMAT_PROLOGUE and FORMAT_EPILOGUE macros. These format opening
and closing stanzas for given element. The FORMAT_PROLOGUE macro
even tries to be clever and format element onto one line (if the
element isn't supported), but that's not enough. Fortunately, we
have virXMLFormatElement() which formats elements properly, so
let's switch macros into using that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In the virDomainCaps struct there are some pointers that might be
NULL (for instance 'sev', 'sgx', 'hyperv'). Teach FORMAT_PROLOGUE
macro to check for NULL argument so that format functions (like
virDomainCapsFeatureHypervFormat()) don't need to.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Make the virDomainCapsCPUFormat() function use
virXMLFormatElement() family of functions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Make the virDomainCapsCPUCustomFormat() function use
virXMLFormatElement() family of functions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The aim of virDomainCapsCPUCustomFormat() is to format CPU models
into given buffer. But it starts by adjusting indentation. Move
this one level up into the caller so that another buffer can be
used. This also makes the pattern match in the caller
(virDomainCapsCPUFormat()) with the rest of CPU related domcaps
formatting.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve supports PCI device passthrough using the following syntax:
bhyve ... -s 4:0,passthru,5/2/0 ...
Where 5/2/0 is PCI address of the device in the host, and "4:0" is the
address in the guest.
Currently, user is responsible for reserving the device for passthrough,
i.e. by configuring pptdevs in loader.conf(5), or using devctl(8) to
detach the device.
Co-authored-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Signed-off-by: Alexander Shursha <kekek2@ya.ru>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After executing the bhyve binary, it might happen that it fails very
early due to configuration issues (missing/inaccessible files, incorrect
custom args), bugs, etc. In this case it'll look like the domain has
started normally, but quickly turned off.
Improve that by waiting for the domain's vmm entity to appear in
/dev/vmm.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Zhaoxin uses two distinct vendor IDs. This patch is adding one of them
used by Zhaoxin YongFeng Processor.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The features defined in our CPU map use quite a bit more than just the
two MSRs the script is currently trying to read. Let's read all of them
to get complete host CPU data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The current code made sense when we were reading only one MSR, but since
we started reading more MSRs, the host CPU would have to support all of
them otherwise the function would just return an empty dict.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When adding a new CPU vendor, we create a new empty group in
src/cpu_map/index.xml and want to use the sync_qemu_models_i386.py
script to add models there.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The GraniteRapids-v2 uses quite a few CPU features unknown to this
script.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This way one can just grep for all warnings in the script output and
still be able to see for which CPU model is defined using features the
script doesn't know about.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
A previous commit removed the 'ret' variable when
switching to subprocess.run, but did not adjust
the exit code.
Fixes: 15c9ca383c
Signed-off-by: Ján Tomko <jtomko@redhat.com>
We've already checked the upper bound of the array, but we should
none the less sanity check that the requested array element is
not NULL before dereferencing it.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All methods must use virCheckStreamReturn to validate their
'stream' parameter.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The subprocess.run command avoids using the shell and so is robust
should sys.argv contain any whitespace or unexpected shell meta
characters.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the `query-accelerators` command to generically query the enabled
acclerator. Below is an example invocation in Qemu:
{ "execute": "query-accelerators"}
"return": {"enabled": "kvm", "present": ["kvm", "mshv", "qtest", "tcg", "xen"]}}
"enabled" here indicates "kvm" is the enabled accelertor.
If query-accelerators command is not available, fallback to existing
mechnisms for querying kvm and hvf capabilities.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce query-accelerators capability which is a generic way to query
the accelerators supported by qemu.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virEventAddHandle/Timeout APIs are unusual in that they do not
report errors on failure, because they call through to function
callbacks which might be provided externally to libvirt and thus
won't be using libvirt's error reporting APIs.
This is a rather unfortunate design characteristic as we can see
most callers forgot about this special behaviour and so we are
lacking error reporting in many cases.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In commit 19fc614d53 I've added an option to configure statistics but
forgot to free it once the disk definition struct is freed.
Fixes: 19fc614d53
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add validation that qemu supports the collection of statistics and
enable it on the block device commandline.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU supports collection of disk statistics in configurable time
windows. Add support for enabling this feature to the conf parser.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The capability tracks support for 'stats-intervals' property of disk
frontends which enables statistics collection on the devices.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The statistics show various disk access timing parameters collected in
configurable interval which can be useful for performance
investigations.
Note that the statistic collection needs to be enabled explicitly for
the statistics to be collected and displayed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'timed_stats' block is a set of statistics gathered in configurable
time intervals. The stats include latency timings of reads/writes as
well as the depth of the request queues.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Management applications can use the detected limits to cross reference
with configuration within the VM to ensure optimal performance.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'limits' field reports various maximum request sizes and
alignments for a qemu blockdev protocol node.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In commit e4d058866e I've converted the code to use the modern
'reconnect-ms' parameter instead of 'reconnect' but messed up the logic
for the time when 'reconnect' will be removed.
We need to check QEMU_CAPS_NETDEV_STREAM_RECONNECT_MILISECONDS
individually and not based on QEMU_CAPS_NETDEV_STREAM_RECONNECT.
Fix the logic as upstream qemu now removed 'reconnect'.
Fixes: e4d058866e
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a note that the filename should match the final version number and
that it's expected to do an update after the given qemu version gets
released.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The only change here is that fuse3 is installed instead of fuse.
This is needed by v11.9.0-9-gb100dabd6d which made the change in
spec file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The meson.build already supports both fuse2 and fuse3, and fuse3
is in all Fedora versions we need, so switch to the newer version
unconditionally.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Not only was ARM 7 dropped from Fedora 37, KVM support has also been
dropped in upstream Linux.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The feature does not do anything, QEMU will always set it according to
the CPU topology completely ignoring what we asked for. Unfortunately,
the way the state of "ht" is reported changed in QEMU 10.0.0 (commit
c6bd2dd634208).
QEMU older than 10.0.0 would just report whatever was specified on the
command line totally ignoring the actual state of the feature visible to
a guest. But after the change QEMU reports ht=on in case it enabled "ht"
based on the CPU topology. In all other cases QEMU still reports the
state requested on the command line.
As a result of this change a domain with multiple CPU threads started on
QEMU < 10.0.0 could not be migrated to QEMU >= 10.0.0 unless "ht" was
explicitly enabled in the domain XML because libvirt would see "ht"
enabled on the destination, but disabled on the source (the guest would
see "ht" enabled in both cases anyway). Outgoing migration of domains
started on QEMU >= 10.0.0 is not affected.
To fix this issue we can completely ignore "ht" both in the domain XML
and in the CPU properties reported by QEMU. With this fix incoming
migration to QEMU >= 10.0.0 works again.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/821
Fixes: https://issues.redhat.com/browse/RHEL-104216
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some features may be on our ignore list because they do nothing even
though QEMU still supports them and reports their state. But as the
features do nothing, the state reported by QEMU may not correspond to
what the guest sees. To avoid possible confusion we may just pretend
QEMU did not report any of the features on our ignore list.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We fix CPUs (i.e., remove ignored CPU features) only when libvirt/QEMU
combo used to start the domain is very old and doesn't support
query-cpu-model-expansion, in which case the CPU definition may contain
features that are unknown to QEMU. But even if both libvirt and QEMU are
new enough, we still want to remove features that do nothing to minimize
confusion or to avoid false migration issues.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function was apparently created when the list of ignored CPU
features contained just cmt and related features. The list grew quite a
bit since then and this function stopped making sense as it would remove
all ignored features from CPU definitions but only if cmt was present.
The issue with cmt is long gone and this function was not really doing
anything. Surprisingly this didn't cause any real issues as we don't
update CPU definitions with features unknown to QEMU. But we may still
want to remove ignored features even though QEMU knows about them for
compatibility reasons.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since virCPUDefFilterFeatures never fails, we can use it for in-place
modifications instead of modifying a temporary virCPUDef copy.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only thing that can fail inside virCPUDefFilterFeatures is
VIR_DELETE_ELEMENT_INPLACE macro. The macro just calls
virDeleteElementsN, which reports a warning when all elements to be
removed are not within the array bounds and returns -1. The function
succeeds otherwise. But since VIR_DELETE_ELEMENT_INPLACE sets the number
of elements to be removed to 1 and we call it with i < cpu->nfeatures,
the safety check in virDeleteElementsN will never fail. And even if we
theoretically called it with wrong arguments, it just wouldn't do
anything.
Thus we can safely assume VIR_DELETE_ELEMENT_INPLACE always succeeds in
virCPUDefFilterFeatures and avoid reporting any errors to simplify
callers.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
VIR_DOMAIN_EVENT_SUSPENDED_API_ERROR=6,/* Some APIs (e.g., migration, snapshot) internally need to suspend a domain. This event detail is used when resume operation at the end of such API fails. (Since: 1.0.1) */
VIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY=7,/* suspended for post-copy migration (Since: 1.3.3) */
VIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY_FAILED=8,/* suspended after failed post-copy (Since: 1.3.3) */
VIR_DOMAIN_EVENT_SUSPENDED_GUEST_SHUTDOWN=9,/* suspended after guest os shut-down (a long running job is preserving the VM until completion) (Since: 11.10.0) */
#~ msgid "only a single IOMMU device is supported"
#~ msgstr "কেৱল এটা TPM ডিভাইচ সমৰ্থিত"
#, fuzzy
#~ msgid "incoming RDMA migration is not supported with this QEMU binary"
#~ msgstr "vhost-net এই QEMU বাইনাৰিৰ সৈতে সমৰ্থিত নহয়"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
