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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
when a device is dynamically attached to a VM, and it needs a special
system access for apparmor, libvirt calls virt-aa-helper (with argument -F)
to append a new rule to the apparmor profile of the VM. virt-aa-helper does
not check for duplicate and blindly appends the rule to the profile. since
there is no rule removal when a device is detached, this can make the profile
grow in size if a big number of attach/detach operations are done and the
profile might hit the size limit and futur attach operations might dysfunction
because no rule can be added into the apparmor profile.
this patch tries to mitigate this issue by doing a duplicate check
when rules are appended into the profile. this fix does not guarantee
the absence of duplicates but should be enough to prevent the profile
to grow significantly in size and reach its size limit.
Signed-off-by: Hector CAO <hector.cao@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Older libvirt versions still only work if 'encryption_key' is enabled
in the server and client certificates. Add a note.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Sebastian Mitterle <smitterl@redhat.com>
Mention that the tls socket needs to be started and the libvirtd
or virtproxyd service might have to be started.
If this is not done the user might run into connection issues and
it seems this is not mentioned elsewhere in the docs.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Sebastian Mitterle <smitterl@redhat.com>
In a recent commit of v11.6.0-25-g5dca0567f6 new config files for
the CH driver were introduced. But corresponding change to the
specfile was missing resulting in a broken rpmbuild. Just put
those files into daemon-driver-ch rpm.
Fixes: 5dca0567f6
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Allow a user to set the verbosity of the cloud hypervisor instances by
specifying it in the ch.conf configuration file.
Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Similar to the QEMU driver, the ch driver receives support for
configuration files that allows doing certain configuration on the
virtchd daemon.
The initial use case will be setting the verbosity of the cloud
hypervisor instances started by virtchd, but the implementation allows
for adding further options.
Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add the ability to enable/disable exposing the EDID information to the guest.
The edid attribute can specified in the domain XML as below:
<video>
<model type='virtio' edid='off'/>
</video>
If the edid attribute is unspecified, it is not generated so that the
virtualisation platform will continue to use its default.
The edid attribute is only valid for the vga, boch and virtio display models
and is currently only implemented for the QEMU driver.
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
MacOS has its own dynamic linker (dyld) which is different to
Linux/BSD one. But with a little help (by setting
"DYLD_FORCE_FLAT_NAMESPACE" env var) it would behave similarly to
Linux/BSD ones. In particular, if a library is preloaded via
"DYLD_INSERT_LIBRARIES" on MacOS or "LD_PRELOAD" on Linux/BSD,
then dlsym(RTLD_NEXT, ...) considers ALL preloaded libraries. For
instance, the virFileCanonicalizePath() is reimplemented in
virpcimock and qemuxml2argvmock. Each one of these
reimplementations uses dlsym(RTLD_NEXT, ...) to look up and call
virFileCanonicalizePath() from next library in the queue and
possibly even the actual implementation from libvirt.so.
This chaining of mocks allows us to have mock libraries that
create stable, reproducible environment for tests.
Now, because of unknown reason Apple decided to remove the flat
namespace feature [1] (I recommend to just clone the repo and
view the commit via 'git show' as github's web interface hides
interesting bits away). They did so in 2022. And it wasn't until
my commit of v11.6.0-19-g12c35ab161 that we've noticed this,
because until that commit no two mock reimplemented the same
function. Well, now they do and with flat namespaces gone the
dlsym(RLTD_NEXT, ...) returns an address from libvirt.so instead
of from next mock on the list.
Since reimplementation of virFileCanonicalizePath() in
qemuxml2argvmock.c is only to cover a case on some Linux systems
and virpcimock.c creates full sysfs imitation of PCI devices, the
latter is more important than the former.
Therefore, switch order of those mocks.
On Linux/BSD this has virtually no effect, but on MacOS it fixes
the qemuxmlconftest failure.
1: 9a9e3e4cfa
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Distros may provide compatibility symlinks after moving firmware files
around, but they won't work for existing VMs when doing a straight
string comparison.
I tried to compare inodes instead, but even glib doesn't provide a
straightforward cross-platform method to do this.
Resolves: https://bugs.gentoo.org/960591
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Soon, the QEMU driver, specifically the part that picks firmware
based on firmware descriptor files (qemu_firmware.c) is going to
check for the presence of those firmware blobs (well, for their
realpath()). Just collect the list of all blobs we use in our
tests and mock virFileCanonicalizePath() so that for any path on
that list its strdup()-ed version is returned.
This means, qemuxmlconftest won't touch host files really.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The caller doesn't check the return value. Remove it to avoid confusing
readers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The hypervisor may return an index out of range of current vCPUs
defined in the domain which would cause a NULL dereference. Validate
that the vCPU struct with ID fetched from hypervisor exists before
dereferencing it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Many callers of 'virDomainDefGetVcpu' don't validate return value when
iterating CPUs up to def->maxvcpus/virDomainDefGetVcpusMax. Remove this
one.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Implement NAT networking support based on the Packet Filter (pf)
firewall in FreeBSD. At this point, the implementation is very basic.
It creates:
- Essential NAT translation rules
- Basic forwarding rules
Implementation uses pf's anchor feature to group rules. All rules live
in the "libvirt" anchor and every libvirt's network has its own
sub-anchor.
Currently there are some assumptions and limitations:
- We assume that a user has created the "libvirt" (nat-)anchors. As
they cannot be created on fly, it's better not to touch global pf
configuration and let the user do the changes. If the user doesn't
have these anchors configured, the rules will still be created in
sub-anchors, but will not be effective until these anchors are
activated. Should we check if these anchors are not active to
give some runtime warning?
- Currently, rule reloading is not smart: it always deletes rules,
flushes rules and re-creates that. It would be better to do that
more gracefully.
- IPv6 configurations are currently not supported
- For NAT, pf requires explicit IP address or an interface to NAT to.
We try to obtain that from the network XML definition, and if it's
not specified, we try to determine interface corresponding to the
default route.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Neither Intel TDX / AMD SEV(SNP) allow use of SMM, but the EDK2
firmware none the less supports secureboot. Libvirt currently
issues bogus warnings about Fedora firmware
warning : qemuFirmwareSanityCheck:1575 : Firmware description
'/usr/share/qemu/firmware/60-edk2-ovmf-x64-inteltdx.json' has
invalid set of features: requires-smm = 0, secure-boot = 1,
enrolled-keys = 1
This removes the warning if the firmware descriptor indicates use
of any confidential VM technology.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This pulls in the fix for libxen which has been removed from armv7
in Debian sid.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
ZFS doesn't have thick allocations, every allocation is
thin-provisioned, so resize operation is essentially
a zvol size limit change
(`zfs set volsize=X pool/zvol_name`).
Shrink is allowed too (which leads to data destruction),
but shrink restriction is already implemented in libvirt,
so this function doesn't need to check anything.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: George Melikov <mail@gmelikov.ru>
Add new 'hwuuid' and 'hwuuid-smbios-uuid-match' tests to verify that the new
hardware UUID (hwuuid) element is working as intended.
In particular the 'hwuuid-smbios-uuid-match' test is designed to ensure that
the hwuuid and smbios UUIDs are always identical, similar to the existing logic
works for the domain UUID and the smbios UUID.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
The hardware UUID (hwuuid) element provides a mechanism to supply an external
UUID to the guest, as opposed to the libvirt domain UUID. This is to allow
for the scenario whereby a domain can be stopped, cloned and then started as
a new domain without altering the guest-visible UUID.
Add the element, documentation and core code for the hwuuid feature along
with an implementation for the QEMU driver.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
The libvirt-lxc.pc.in and libvirt-qemu.pc.in files had the
incorrect package name, though fortunately this appears to
have been a harmless mistake.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When using the 'run' script, we point pkg-config to files
in $BUILD/src, which resolve to the local build tree.
Unfortunately we forgot a libvirt-admin.pc.in, so the run
script was not taking effect for the admin APIs.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Convert the member to the appropriate type, fix few missing cases
in switch() and switch to virXMLPropEnum() in parsing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virNetDevVPortProfile enum is both explicitly declared and
also typedef-ed. This repetition is redundant. Just use typedef.
To make matters worse, there's another type with the same name,
but because in the code, those few places used 'enum
virNetDevVPortProfile var;' to declare variables compilers didn't
complain.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When TD VM reboot, qemu process is recreated by destroying old and
creating new one. When new qemu process starts, it sends a RESUME
event while libvirt domain isn't in run state yet. Then event
VIR_DOMAIN_EVENT_RESUMED is sent out and confuse control plane.
Check priv->pausedShutdown and bypass the event for TD VM, for
normal VM, domain is in run state and already bypassing it.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
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 canonicalization of the paths is not mocked properly and thus the
tests depend on the host system. While the tests do pass on our CI they
break on real deployments at least on Fedora 42.
Since we're in code freeze for the upcoming release, revert the patch
instead of attempts to fix it.
This reverts commit 4efea21ae8.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Turns out the test difference was not caused by forgotten hunks but
rather that the test output depends on the system.
For now both this wrong fix and the commit causing the failure will both
be reverted as we're in code freeze for the upcoming release.
This reverts commit 73345ccc7b.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commit 4efea21ae8 modified how the EFI
paths are detected but didn't update the outputs.
Fixes: 4efea21ae8
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Distros may provide compatibility symlinks after moving firmware files
around, but they won't work for existing VMs when doing a straight
string comparison.
I tried to compare inodes instead, but even glib doesn't provide a
straightforward cross-platform method to do this.
Resolves: https://bugs.gentoo.org/960591
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The description says it "resolve all symlinks", but it was only
resolving the last component.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
New event reasons were added in
commit 1af740c501
Author: Zhenzhong Duan <zhenzhong.duan@intel.com>
Date: Thu Jul 10 03:21:21 2025 -0400
qemu: Send event VIR_DOMAIN_EVENT_[STOPPED|STARTED] during recreation
but the naming did not match existing reason names, so adapt
to match. The version tags are also updated to reflect when
this was merged.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow to define the default for deprecated_features when the attribute
is not set in the cpu defintion of a domain XML. If these features are
still desired, they may be reenabled via the deprecated_features='on'
attribute.
Some existing tests utilize this updated behavior, so update the CPU
features on the corresponding args files.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Add tests for active/inactive XML with deprecated_features attribute.
Note that for the qemuxmlactivetest, it is not possible to test an
inactive guest XML with the absence of "deprecated_features" attribute
and expect the active XML to have the attribute present. This is due to
the fact that the tests never touch the code path in qemu_process that
trigger this change in the domain definition.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Group up the deprecated features code into a single block to keep things
clean; only check if the deprecated_features attribute is present
once and then do relevent work.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Currently, virQEMUCapsUpdateCPUDeprecatedFeatures only allows for
disabling deprecated features. This locks the deprecated_features
attribute to only do something if set to 'off'.
Let's add a virCPUFeaturePolicy to the function's parameters which will
allow the caller to decide what happens to these features.
Add a test with guest XML using deprecated_features='on' to ensure the
API is working properly.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Provide documentation for the deprecated_features XML attribute.
Available since 11.0.0, and supported for S390.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
We now have the '+inteltdx' variant dumped from a modern qemu with tdx support,
add qemuxmlconftest data for that variant.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
TDX guest doesn't support system_reset, so have to kill the old QEMU and
start a new one to simulate the reset. This can be achieved by calling
qemuProcessFakeRebootViaRecreate().
Simiar as FakeReboot, QEMU sends SHUTDOWN event with "host-signal" reason
which can trigger another FakeReset. Check if a FakeReset is ongoing and
bypass "host-signal" processing which originally comes from FakeReset.
Domain lock is already hold in qemuDomainReset() before calling
qemuProcessFakeRebootViaRecreate(), so bypass locking in it.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For secure guest, FakeReboot kills original QEMU instance and
create new one which is quite different from normal guest.
To reflect this fact, VIR_DOMAIN_EVENT_[STOPPED|STARTED]
are sent to control plane with new introduced reasons
VIR_DOMAIN_EVENT_[STOPPED|STARTED]_RECREATION.
That would let control plane software understand that these
events are from a fake reboot.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
For secure guest, FakeReboot kills original QEMU instance and
create new one. During this process, QEMU send SHUTDOWN event
with "host-signal" reason which can trigger another FakeReboot.
Check if a FakeReboot is ongoing and bypass "host-signal"
processing which originally comes from FakeReboot.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We can reboot a TDX guest with 'virsh reboot' or 'virsh shutdown' if action
for onPoweroff is 'restart'. But running reboot command in guest shell will
always lead to shutdown.
This behavior is not consistent with normal guest, fix it by checking
shutdown reason and action configuration to trigger FakeReboot.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Utilize the existing fake reboot mechanism to do reboot for TDX guest.
Different from normal guest, TDX guest doesn't support system_reset,
so have to kill the old guest and start a new one to simulate the reboot.
Co-developed-by: Chenyi Qiang <chenyi.qiang@intel.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
'tdx-guest' object supports a "quote-generation-socket" property for
attestation purpose. When "quote-generation-socket" is configured in
guest xml, libvirt generates unix socket format cmdline for QEMU.
'Path' element can be omitted, default path "/var/run/tdx-qgs/qgs.socket"
is used in this case.
QEMU command line example:
qemu-system-x86_64 \
-object '{"qom-type":"tdx-guest","id":"lsec0","mrconfigid":"xxx","mrowner":"xxx","mrownerconfig":"xxx","quote-generation-socket":{"type":"unix","path":"/var/run/tdx-qgs/qgs.socket"},"attributes":268435457}' \
-machine pc-q35-6.0,confidential-guest-support=lsec0
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add element "quoteGenerationService" to tdx launch security type.
It contains only an optional unix socket address attribute,
when omitted, libvirt will use default QGS server address
"/var/run/tdx-qgs/qgs.socket".
UNIX sockets offer the required functionality with greater
security than vsock, so libvirt only provides support for unix
socket.
XML example:
<launchSecurity type='tdx'>
<policy>0x10000001</policy>
<mrConfigId>xxx</mrConfigId>
<mrOwner>xxx</mrOwner>
<mrOwnerConfig>xxx</mrOwnerConfig>
<quoteGenerationService path='/var/run/tdx-qgs/qgs.socket'/>
</launchSecurity>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
The firmware descriptors have 'intel-tdx' feature which
describes whether firmware is suitable for TDX guests.
Provide necessary implementation to detect the feature and pick
the right firmware if guest is TDX enabled.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Since QEMU 10.1.0 commit id '6e250463b08b' guest crash information for
TDX is available in the QEMU monitor, e.g.:
{
"timestamp": {
"seconds": 1752118704,
"microseconds": 27480
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause",
"info": {
"error-code": 0,
"message": "TD misconfiguration: SEPT #VE has to be disabled",
"type": "tdx"
}
}
}
Let's log this information into the domain log file, e.g.:
2025-07-10 03:39:18.243+0000: panic tdx: error_code='0x0' message='TD misconfiguration: SEPT #VE has to be disabled'
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
TDX guest requires some special parameters to boot, currently:
"kernel_irqchip=split"
"pmu!=on"
"smm!=on"
"-bios"
If not specified explicitly, QEMU should configure this option implicitly
when start a TDX guest.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
As the tdx launch security type support is added, expose it in domain
capabilities so that domain definition validation check can take
effect.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU will provides 'tdx-guest' object which is used to launch encrypted
VMs on Intel platform using TDX feature.
Command line looks like:
$QEMU ... \
-object '{"qom-type":"tdx-guest","id":"lsec0","mrconfigid":"xxx","mrowner":"xxx","mrownerconfig":"xxx","attributes":268435457}' \
-machine pc-q35-6.0,confidential-guest-support=lsec0
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
mrConfigId/mrOwner/mrOwnerConfig are base64 encoded SHA384 digest,
can be provided for TDX attestation.
Check their decoded lengths to ensure they are 48 bytes.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When 'tdx' is used, the VM will be launched with Intel TDX feature enabled.
TDX feature supports running encrypted VM (Trust Domain, TD) under the
control of KVM. A TD runs in a CPU model which protects the confidentiality
of its memory and its CPU state from other software.
There are four optional child elements. Element policy is 64bit hex, bit 0
is set to enable TDX debug, bit 28 is set to enable sept-ve-disable, other
bits are reserved currently. When policy isn't specified, QEMU will use its
own default value 0x10000000. mrConfigId, mrOwner and mrOwnerConfig are
base64 encoded SHA384 digest string.
For example:
<launchSecurity type='tdx'>
<policy>0x10000001</policy>
<mrConfigId>xxx</mrConfigId>
<mrOwner>xxx</mrOwner>
<mrOwnerConfig>xxx</mrOwnerConfig>
</launchSecurity>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Upcoming patch will introduce test data from an TDX-enabled host.
Document the new variant.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Implement TDX check in order to generate domain feature capability
correctly in case the availability of the feature changed.
For INTEL TDX the verification is:
- checking if "/sys/module/kvm_intel/parameters/tdx" contains the
value 'Y': meaning TDX is enabled in the host kernel.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Currently, libattr is detected using cc.find_library() because at
historically, the library was lacking pkg-config file. But that
changed with libattr-2.4.48 (released 7+ years ago) and even
prehistoric distros have it now. Switch to dependency().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
While historically we've stored the 'pool' and 'image' properties of RBD
and gluster images in separate fields but they are presented in a single
field in the XML. This creates multiple points where they need to be
separated and combined.
Introduce helper 'virStorageSourceNetworkProtocolPathSplit' which will
do that at the point of use rather than everywhere in the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Automatically free 'priv' and call 'glfs_fini()' directly from the two
error paths.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Convert the member to the appropriate type, fix few offending parse
calls and remove explicit typecasts in switch().
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactored the qemuDomainObjPrivateXMLParseVcpu function to use the
appropriate virXMLPropUInt function to parse unsigned integers,
avoiding unccessery string parsing operations.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactored the default case port option parsing logic to use the
appropriate virXMLPropInt function.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactored the virSecretLookupParseSecret fucntion to use the
virXMLPropUUID fucntion, avoid getting the string and parsing it
later. Previously two separate error states merged into one by using
boolean NXOR operation.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactored the virNetDevVPortProfileParse function to use the appropriate
virXMLProp* functions to parse input configuration XML.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch corrects the header comment for virBitmapNextClearBIt.
Currently, the header comment reads:
`@pos can be -1 to search for the first set bit.`
However, this statement is false.
We can prove this by referencing the virbitmaptest functions, i.e
virbitmaptest.c:223, in which i = 0
if (virBitmapNextClearBIt(bitmap, -1) != 0)
return -1
Because this is a zero set, this case would fail if the header statement was true as is.
Signed-off-by: Aaron M. Brown <aaronmbr@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Automatically free temporary variables in order to remove 'cleanup'
section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically free temporary variables in order to remove 'cleanup'
section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use automatic freeing of temporary variables and remove cleanup section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the new autoptr helper to free the temporary variables and refactor
cleanup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The selinux headers have a 'typedef context_s_t *context_t;' definition
in the header so we declare autoptr cleanup function for 'context_s_t'
and use it instead of 'context_t' definitions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically free temporary variables and remove the need for 'cleanup'
section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically free temporary variables and change 'cleanup' label to
'error'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Declare 'in'/'out' only in the bocks which use them and automatically
free them. Since cleanup section was removed we don't need a 'ret'
variable any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Declare 'path' only in blocks where it's used and autofree it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Declare 'filename' inside the loop that is using it and use automatic
freeing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically free 'fcon' and 'newpath' and remove the 'cleanup' label
and 'ret' variable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fix the misaligned arguments by switching over to modern style.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upon VM bootstrapping (start,restore,incoming migration)
iptablesCreateBaseChainsFW is called and unconditionally deletes and
reinserts top-level firewall chain jumps (e.g. INPUT, FORWARD rules).
This briefly allows packets to continue, allowing packets through
until the base chain iptables -I commands run.
This commit ensures that the base chains are only created once per layer
(IPV4/IPV6) and checks whether the expected rules already exist using
`iptables -L`. If they do, no delete/insert operations are performed.
By checking for the existence of rules we can prevent more rules from
being created if they already exist. Possibly speeding up nwfilter by
reducing the amount of iptable commands it executes. This however is not
part of this patch.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/784
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
QEMU will either use the GNUTLS default priority string of "NORMAL",
or on Fedora/RHEL related distros, "@QEMU,SYSTEM", which resolves to
a configuration in /etc/crypto-policies/back-ends/gnutls.config.
The latter gives the sysadmin the ability to change the priority
string used for GNUTLS at deployment time, either system side, or
exclusively for QEMU, avoiding the hardcoded GNUTLS defaults.
There are still some limitations to this:
* Priorities cannot be set for different areas of QEMU
functionality (migration, vnc, nbd, etc)
* Priorities are fixed at the time when QEMU first
triggers GNUTLS to load its config file, often
immediately at startup.
We recently uncovered a QEMU bug that causes crashes in live
migration with TLS-1.3, where the easiest workaround is to
change the TLS priorities. We can't change this on the running
QEMU, but fortunately it is possible to change it on the target
QEMU and the TLS handshake will make it take effect on both
src and dst.
The problem is, while fixing the immediate incoming and outgoing
live migration problems, the workaround will apply to everything
else that QEMU does for the rest of the time that process exists.
We want to make it possible to set the TLS priorities only for
the current migrations, such that if the target QEMU has a fixed
GNUTLS, it will not have its TLS priorities hobbled for the next
live migration.
To achieve this we need libvirt to be able to (optionally) set
the TLS priority string with QEMU. While live migration is the
most pressing need, the new qemu.conf parameters are wired up
for every subsystem for greater selectivity in future.
With this we can activate the GNUTLS workaround for running
QEMU processes by editting qemu.conf and restarting virtqemud,
and later undo this the same way.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We mostly use 2 blank lines between config file entries to
improve readability. Fix where we don't do that.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
For TLS config parameters, the 'verify' option always comes before the
'secret_uuid' option, except in the VNC case which has them reversed.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The bhyveload(8) command does not have a native non-interactive mode.
It means that in case of errors, e.g. invalid boot media, it
just drops into a loader prompt and waits for user input. This behaviour
makes it tricky for users to understand what's going on.
To address that, run it with the timeout(1) tool which sends SIGTERM
after a certain timeout, and then optionally sends SIGKILL if the
command keeps hanging.
These timeout values could be configured in the bhyve.conf. Setting
timeout to 0 mean that bhyveload(8) will be executed directly, without
timeout(1).
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, virBhyveProcessStop() uses the virDomainDeleteConfig()
helper to clean up domain status. It passes BHYVE_STATE_DIR as
a configuration dir and NULL as autostart dir, so the helper does its
job, even though it has a different purpose. However, the issue is that
it also resets the autostart (and autostartOnce) property.
This results in a situation that when a persistent domain with autostart
enabled gets destroyed, its autostart state is reported as disabled,
which is not correct.
To fix that, implement the bhyveProcessRemoveDomainStatus() which
removes the status file without side effects on the virDomainObj object.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com
Commit 3451987fca used the persistent TPM Definition in both calls to
qemuTPMVirCommandSwtpmAddTPMState() but in one of the two cases it
might've been NULL and what's more, it is not the right definition which
should've been used. Change that to @tpm which is the current
definition. The other call does not have access to the current
definition and is only called during updating the profile. But for the
sake of fewer future mistakes, keep the other one as is because there is
no issue with calling it that way and adding logic that just skips the
extra check on NULL could mistake someone in the future.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
It may help in case the NSS plugin ever faces a corrupted JSON
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As promised in previous commit, make NSS modules silent by
default and enable debug printings if LIBVIRT_NSS_DEBUG envvar is
set.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, when somebody wants to debug the NSS plugin, they have
to change a line in libvirt_nss.h (to enable debug printings) and
recompile the module. This may work for us, developers, but we
can not expect this from users.
For now, this turns debug printings unconditionally on. Making it
conditional on an envvar is handled in the next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The difference between DEBUG() and ERROR() macros is that the
latter also prints (stringified) errno. Inside of findLease()
there's one line where time() is called which is documented as:
On error, ((time_t) -1) is returned, and errno is set to
indicate the error.
Therefore, don't just print DEBUG() but ERROR() so that the cause
for the error is printed too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function can load a generic list of certs, it doesn't necessarily
have to be the list of CAs. Rename the function, and change error to be
generic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Use autofree for all temporary variables and return the result directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
With this new flag virConnectHypervisorBaselineCPU can be used on any
host (rather than being limited to hosts described by individual CPUs
passed to the API). Using the flag makes the API behave similarly to the
old virConnectBaselineCPU. The main difference is the CPU definition
accepted by both APIs: the old one only accepts host CPU definition,
i.e., without 'policy' attributes as seen in the host capabilities XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Moving the documentation above each enum item gives us more space for
it.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The API was apparently never considered for being used on a host that is
not represented in the input set of CPU definitions. The result is
limited to the set of features and CPU models known to the host's
hypervisor. This would likely not be a big issue, but thanks to a side
effect of commit v3.8.0-99-g9c9620af1d usability blockers come to play
as well. When converting CPU data (CPUID and MSR bits) to each named
model for comparison, we disable features that block usability of the
model on the current hypervisor, the rest of the features are set
according to the data without taking host capabilities into account.
Thus the process of comparing and selecting the most appropriate CPU
model for the given data is significantly influenced by the host, but it
doesn't behave as if the host CPU model was included in the input data.
The documentation tried to say the result was tied to the host's
hypervisor, but it wasn't very clear.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Inside to qemu_tpm.c there are three functions that use the same
pattern (qemuTPMEmulatorRunSetup(), qemuTPMEmulatorReconfigure()
and qemuTPMEmulatorUpdateProfileName()):
int exitstatus;
...
if (virCommandRun(cmd, &exitstatus) < 0 || exitstatus != 0) {
virReportError(..., exitstatus);
return -1;
}
Problem with this pattern is that if virCommandRun() fails then
exitstatus is left untouched and a garbage value is then passed
to virReportError().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With a help from coccinelle three places were identified that
call virReportError() after failed open() (in
qemuDomainWriteMasterKeyFile(), qemuDomainMasterKeyReadFile() and
qemuProcessOpenVhostVsock()). The open() syscall does set errno
on failure so switch them to virReportSystemError() which may
shed more light into the reasons for failure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similar branches in the if-else structure look like bad copy-paste.
Fix the typo.
Fixes: a559ffec44 (src: rewrite ACL rule checker in Python)
Signed-off-by: Elizaveta Tereshkina <etereshkina@astralinux.ru>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the same error messages for serial devices validation which are
already used in bhyve_domain.c
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Extend bhyveDomainDeviceDefValidate() to check that:
- only 'nmdm' or 'tcp' serial devices are used,
- serial device count is not more than supported,
- only listening raw TCP sockets are used.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Recent versions of bhyve support 4 com ports instead of just 2. Thus,
allow to use 4 console devices.
Also, there was a bug previously because the condition was
"if (chr->target.port > 2)", but as target.port start
with 0 and "com" ports start with 1, this condition allows com3 to be
used.
As bhyve supports 4 com ports already long enough, and all supported
FreeBSD versions include this capability, do not introduce driver
capability for that.
Add a couple of tests for that:
- A domain that uses 4 serials, 2 of type 'nmdm'
and the other 2 of type 'tcp'
- A domain that uses unsupported port, such as target.port=4 which
translates into com5.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In addition to the nmdm consoles, bhyve also supports a tcp console.
It's configured with:
.. -l com1,tcp=127.0.0.1:12345
Then a user could connect to the guest console port 0 by making a tcp
connection to the host's 127.0.0.1:12345.
In the domain XML this configuration is represented as:
<serial type='tcp'>
<source mode='bind' host='127.0.0.1' service='12345'/>
<target type='serial' port='0'/>
</serial>
Also, update domain capabilities to include the TCP console support.
Unfortunately, there's no way to detect that from the bhyve binary
before trying to start a VM, so there's no capability probing for this
feature.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The warning pollutes the logs and might give a bad impression on someone
reading them even though the locking is not always needed. This way we
at least limit the logging in unnecessary cases.
Resolves: https://issues.redhat.com/browse/RHEL-80155
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This way we can do the check for a particular TPM also elsewhere in the
code, especially in places where we're dealing with only one TPM. The
semantics is changed a little bit in a way that the function will check
all the TPMs as opposed to stopping on the first one which is of the
emulator type, but since a domain can currently only have one of these
it was not an issue.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The function deals with the whole domain and the part that handles one
TPM will be useful elsewhere and hence extracted later. This rename
makes it possible for the new function to use the original name of this
renamed one.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
xmlCopyNode() may return NULL. Add a check and log an error
in this case.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Fixes: 22766a1a53 ("virshFindDisk: Sanitize use of 'tmp' variable")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We need to check obj ptr before passing it to
virJSONValueObjectHasKey(). If it's NULL it will fail with SIGSEGV.
Signed-off-by: Nikolai Barybin <nikolai.barybin@virtuozzo.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We have virFileCanonicalizePath() which calls realpath() but
also is present in our mocks (in contrast to realpath()).
Introduce a syntax-check rule to enforce use of our wrapper.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refactored the virDomainHostdevSubsysMediatedDevDefParseXML function
to use virXMLPropUUID fuction instead of getting a string and parsing
it later.
Due to parsing function change the missing uuid error reporter and
message were changed and changed error message was also reflected in
tests' outputs.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Introduce schema for the host '<sysinfo>' output XMLs and validate our
test data against the schema.
This requires introduction of schema for '<processor>' and
'<memory_device>' elements which are not supported when sysinfo is set
explicitly for a domian definition.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract the common bits of the domain definition <sysinfo> schema which
will be also later reused to construct schema for the host <sysinfo> top
level element.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
--werror does not accept any arguments for me and setting
git_werror was also needed to disable it with git.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
DM_TABLE_DEPS expects a device name in dm_ioctl.name. In one of the
cases, full path of the device was getting returned causing the ioctl
call to fail with `ENXIO (No such device or address)`.
Also rename the function and variable names to better reflect that we
are dealing with DM device names and not paths.
This got introduced in 2249455654
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/790
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Bhavin Gandhi <bhavin192@geeksocket.in>
The example allows packets sent by qemu after migration with broken
protocol ID. The proper self announce is handled via
'qemu-announce-self-rarp'.
The qemu bug was addressed by f8778a7785d530515b0db39 (released as
v0.13.0). As we no longer support such old qemus, and allowing broken
packets makes no sense. Remove the rule and make it into an alias of
'qemu-announce-self-rarp' to preserve compatibility. Adjust the existing
examples to use only the proper rule.t
Closes: https://gitlab.com/libvirt/libvirt/-/issues/792
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Data based on 'v10.0.0-1874-gc77283dd5d'.
Notable changes:
- machine types:
- added 10.1 machines
- dropped old machine types up to '4.1' (oldest supported is now '4.2)
- new devices 'vfio-iommu-user', 'vfio-user-pci'
- new qom types 'tdx-guest' (including additions to GUEST_CRAS* events
etc), 'ram-block-attributes'
- CPU stuff:
- new models: 'EPYC-Turin-x86_64-cpu',
- new model versions: 'EPYC-Genoa-v2-x86_64-cpu', 'EPYC-Milan-v3-x86_64-cpu'
'EPYC-Rome-v5-x86_64-cpu', 'EPYC-v5-x86_64-cpu'
- new flags: 'fs-gs-base-ns', 'prefetchi', 'its-no msr-imm'
- keep-alive options added to all types using 'inet' socket addreses
- Some platform specific QMP commands are now reported on all
platforms:
- 'query-gic-capabilities'
- 'query-cpu-model-baseline'
- 'query-cpu-model-comparison',
- 'dump-skeys'
- 'set-cpu-topology' (unstable)
- 'query-s390x-cpu-polarization' and corresponding 'CPU_POLARIZATION_CHANGE' event (unstable)
- blockdev stuff:
- blockdev-backup 'on-cbw-error' property added
- blockdev-mirror 'target-is-zero' property added
- deprecated commands: 'block-job-complete', 'block-job-dismiss',
'block-job-finalize', 'block-job-pause',
'block-job-resume'
- 'dpofua' parameter of scsi disks was now enabled by default
- 'migrate-extra' flag of 'virtio-net' removed
- virtio devices gained 'sriov-pf' parameter
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
New qemu is deprecating 'pc-q35-4.0-machine', update to the latest
released machine type.
Apart from the previous cases where we could use the aliased machine
type, the firmware auto-selection doesn't work properly for the
unexpanded 'q35' alias and thus we need to use a real machine type here.
Outside of tests a real machine type would be filled anyways, the use of
the alias happens only inside our '-latest' test suite.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
New qemu is deprecating 'pc-i440fx-4.0-machine', update to the latest
released machine type.
Apart from the previous cases where we could use the aliased machine
type, the firmware auto-selection doesn't work properly for the
unexpanded 'pc' alias and thus we need to use a real machine type here.
Outside of tests a real machine type would be filled anyways, the use of
the alias happens only inside our '-latest' test suite.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
New qemu will be deprecating them. Drop the use from test files not
depending on the actual machine type.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
New qemu will be deprecating them. Drop the use from test files not
depending on the actual machine type.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
New qemu will be deprecating them. Drop the use from test files not
depending on the actual machine type.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
New qemu will be deprecating them. Drop the use from test files not
depending on the actual machine type.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
As TLS 1.3 performs key exchange separately from the algorithm used to
verify authenticity, the certificates for libvirt's use of TLS don't
need to require the 'encryption_key' feature any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Key encipherment is required only for RSA key exchange algorithm. With
TLS 1.3 this is not even used as RSA is used only for authentication.
Since we can't really check when it's required ahead of time drop the
check completely. GnuTLS will moan if it will not be able to use RSA
key exchange.
In commit 11867b0224 I tried to relax the check for some eliptic
curve algorithm that explicitly forbid it. Based on the above the proper
solution is to completely remove it.
Resolves: https://issues.redhat.com/browse/RHEL-100711
Fixes: 11867b0224
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Decide separately and record what shutdown modes are to be applied on
given VM object rather than spreading out the logic through the code.
This centralization simplifies the conditions in the worker functions
and also:
- provides easy way to check if the auto-shutdown code will be acting
on domain object (will be used to fix attempt to auto-restore of
VMs which were not selected to be acted on
- will simplify further work where the desired shutdown action will be
picked per-VM
This refactor also fixes a bug where if restoring of the state is
applied also on VMs that are not selected for action based on current
logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commit 84bb136c31 added code that intended to skip the save of
transient domains but did so only in the setup part where we pause the
VMS. The second loop that actually attempts to save the VM was not
modified so we'd still try saving them:
Jul 03 14:15:13 andariel virtqemud[247210]: auto-shutdown: unable to perform managed save of 'cd3': Requested operation is not valid: cannot do managed save for transient domain
Fixes: 84bb136c31
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
'virDomainDriverAutoShutdown' grew into an unwieldy function. Extract
the code for each of the save/shutdown/poweroff steps into helpers and
call them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When auto-shutdown via the qemu driver is requested (rather than via
libvirt guests) we need to start the VMs in a way that they will be kept
around for libvirt to terminate them. This involves inverting the
dependancy relationship for the machined unit file.
Since the setup is done at startup of the VM, add a disclaimer to
qemu.conf that switching between the two modes with VMs running will not
work properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Plumb the new argument across the cgroup helpers up to the domain driver
code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The existing dependency order of the 'machined' unit file for the domain
we're starting ("After libvirtd/virtqemud"->thus shuts down *before* the
daemon) is intended to work with 'libvirt-guests.service' which requires
the daemon to be around to shut down the VMs.
If we want to use the integrated auto shutdown done by the daemon itself
we need to be able to instruct the domains (thus the corresponding
machined units to shut down *after* virtqemud/libvirt.
This means that we need to be able to invert the ordering relationship
to "Before".
This patch adds a parameter to virSystemdCreateMachine so that when
starting the VM we'll be able to tell the daemon to use the proper
relationship.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Extract the checker that determines whether the daemon auto shutdown
functionality is active to a separate helper
'virDomainDriverAutoShutdownActive'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Rather than having a bunch of extra variables save the configuration of
the daemon auto shutdown in virDomainDriverAutoShutdownConfig which is
also used when initiating the shutdown.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The function is called just from one place within the module where it's
defined.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The parameter overrides the maximum number of threads for the machine.
Fixes: d5572f62e3
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Using lsilogic on RISC-V was never an actual decision, but
rather a consequence of that being the default for legacy x86
guests. Using virtio-scsi is a much more sensible choice.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use a better order for sections, improve comments, tweak
formatting.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Make the helper stateless. This requires the caller to check
whether it needs to be called in the first place instead of
adding this check inside the function, which makes for more
readable, if a little more verbose, code.
We also update callers to check the return value against
VIR_DOMAIN_CONTROLLER_MODEL_SCSI_DEFAULT instead of a
functionally equivalent, but semantically less meaningful,
check for whether the return value is negative.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Similar to x86, the default SCSI controller model for ARM is lsilogic.
But unlike x86, the ARM virt machine type prefers virtio devices. Switch
the default controller model for ARM from lsilogic to virtio-scsi.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Use the same wording as for SCSI controllers, which also
happens to contain additional information (the controller's
index).
The new error message and error type are more accurate anyway:
in most cases, it's perfectly fine for the user not to provide
a controller model explicitly, as libvirt will try to figure
out a reasonable default.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We want this helper to work more like other similar ones, where
error reporting is performed by the caller. This introduces a
small amount of code duplication but makes for a cleaner API.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The original name was qemuDomainGetSCSIControllerModel().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This provides coverage for the (very unlikely) scenario in
which none of the possible devices are built into QEMU.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Instead of treating -d and -v arguments as positional, use
getopts to parse cmd line arguments passed to
virt-aa-helper-test script.
While at it, introduce -h for printing basic help describing each
argument.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After previous cleanup the cleanup label is no longer necessary.
Drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Inside of get_files() there are two cases where vah_add_file() is
not checked for its retval. This is possibly dangerous, because
vah_add_file() might fail. Fix those places by introducing checks
for the retval.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The @mem_path variable inside of get_files() is used only within
a single block. Move its declaration inside it. And also utilize
automatic memory freeing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way virt-aa-helper works is the following: the apparmor
secdriver formats domain XML, spawns virt-aa-helper process and
feeds it with domain XML (through stdin). The helper process then
parses the XML and iterates over devices, appending paths in each
loop.
These loops usually are in the following form:
for (i = 0; i < ctl->def->nserials; i++) {
if (ctl->def->serials[i] && ...
}
While we are probably honourable members of tautology club, those
NULL checks are redundant. Our XML parses would never append NULL
into def->devices array. If it did, we're in way bigger problems
anyway.
Then, constantly dereferencing ctl->def just to get to a path
that's hidden a couple of structures deep gets hard to read. Just
introduce temporary variables.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For an USB device, the virt-aa-helper must put that
/dev/bus/usb/... path associated with given device. The way the
code is currently written not only leads to a memleak (the @usb
variable is allocated only to be overwritten right away), but is
needlessly cumbersome.
We can use virHostdevFindUSBDevice() to find the USB device,
check if its missing and if not add the path associated with it
into the profile.
While at it, also use automatic memory freeing for the variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our test suite is very feature rich. In particular, it has two
mocks that implement sysfs close enough to create
host-independent environment to work with PCI and USB devices.
These mocks are called virpcimock and virusbmock, respectively.
Inside of virt-aa-helper-test there is an attempt to test whether
virt-aa-helper generates profiles for <hostdevs/>, once for USB
and the other time for PCI. Use this mocks to run virt-aa-helper
in an environment where certain PCI/USB devices always exist.
There are two problem though:
1) those two test cases use hardcoded PCI/USB addresses, which
makes them host environment dependant,
2) neither of the test cases checks whether corresponding rule
was added into the profile.
Using mocks we can get away with problem 1), and by passing the
fifth argument to testme() we can list an expected rule in the
profile.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virt-aa-helper checks presence of files before it adds them into
a profile. Because of that, test cases inside of
virt-aa-helper-test that require presence of /boot/initrd* are
guarded by a check. The check uses ls to find at least one initrd
file. If there's none, then ls prints an error onto stderr. This
is not helpful because the test script prints a message on its
own right after.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When a test case fails, there are two echo-s executed: the first
one either prints the error message into /dev/null (default) or
onto stdout (when the test script is executed with -d). Then, the
second one prints the error message onto stdout. While this
technically works, there's nothing ever printed onto stderr which
is usually what's captured. Worse, if some command within the
script fails, it prints something onto stderr but then looking at
meson logs it's needlessly hard to match stderr and stdout lines.
Just print error messages onto stderr.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In some cases (well, majority), open() is either rewritten to
open64(), either by plain '#define open open64') or at assembly
level (using __REDIRECT macro). See <fcntl.h> for more info.
This didn't really matter to us, because we do not chain load two
mocks that would need to reimplement open() at the same time. But
this is soon going to change.
The problem is, that VIR_MOCK_REAL_INIT(open) glances over
aforementioned rewrite and initializes real_open pointer to
open() from the standard C library. But it needs to point to
open() (well, open64()) from the next mock on the list.
Therefore, init real_open to open64().
But of course, this is all glibc specific and for example musl
does the oposite (#define open64 open).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The mocked implementation of virFileCanonicalizePath() redirects
accesses to few dirs into a temporary directory, where PCI
related files live. See getrealpath() for more info on this.
Anyway, in the end - real implementation of
virFileCanonicalizePath() is called which then might contain the
'fakerootdir' prefix. Up until now this did not matter because
none of our test really cared about actual value of resolved
path. They usually cared about last component of the path or
something. But this will soon change.
TLDR - if the returned path has $fakerootdir prefix, strip it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, all users of virpcimock do set LIBVIRT_FAKE_ROOT_DIR
envvar. But soon, virt-aa-helper will be run with it and
basically right at the beginning of its main() it clears whole
environment. So even if the envvar is provided the mock won't see
that.
Anyway, the solution is to just create a tempdir and then 'rm
-rf' it in the desctructor.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While use of realpath() is not forbidden, our some of our mocks
already have a test friendly reimplementation of
virFileCanonicalizePath(). Use the latter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While use of realpath() is not forbidden, our some of our mocks
already have a test friendly reimplementation of
virFileCanonicalizePath(). Use the latter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This patch is useless.
Either APIs it don't have 'resource' nor 'bandwidth' argument to
begin with, or they serve as a wrapper over different API
(changed in previous commits). Nonetheless, in the name of
consistency, let's just change those variable names.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are still some functions around migration code that use
'resource' instead 'bandwidth'. Rename the variable/argument
inside them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainMigratePerform3() API declares its last argument as
'bandwidth', though throughout various typedefs, RPC and callback
implementations the name is changed to 'resource'. This creates a
confusion. Unify the name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainMigrateBegin3() API declares its last argument as
'bandwidth', though throughout various typedefs, RPC and callback
implementations the name is changed to 'resource'. This creates a
confusion. Unify the name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainMigratePrepareTunnel3() API declares one of its
argument as 'bandwidth', though throughout various typedefs, RPC
and callback implementations the name is changed to 'resource'.
This creates a confusion. Unify the name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainMigratePrepare3() API declares one of its argument
as 'bandwidth', though throughout various typedefs, RPC and
callback implementations the name is changed to 'resource'. This
creates a confusion. Unify the name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainMigratePrepareTunnel() API declares one of its
argument as 'bandwidth', though throughout various typedefs, RPC
and callback implementations the name is changed to 'resource'.
This creates a confusion. Unify the name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainMigratePrepare2() API declares one of its argument as
'bandwidth', though throughout various typedefs, RPC and callback
implementations the name is changed to 'resource'. This creates a
confusion. Unify the name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainMigratePerform() API declares its last argument as
'bandwidth', though throughout various typedefs, RPC and callback
implementations the name is changed to 'resource'. This creates a
confusion. Unify the name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainMigratePrepare() API declares its last argument as
'bandwidth', though throughout various typedefs, RPC and callback
implementations the name is changed to 'resource'. This creates a
confusion. Unify the name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
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>
Add a test case for explicitly selected USB disk models.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
usb-storage is a compound device that automatically creates a USB mass
storage device and a SCSI device as its backend. Unfortunately it lacks
some configuration options that are usually present with a SCSI device,
and cannot represent CD-ROM in particular.
Replace usb-storage with usb-bot, which can be combined with a manually
created SCSI device. libvirt will configure the SCSI device in a way
identical with how QEMU does for usb-storage except that now it respects
a configuration option to represent CD-ROM.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/368
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Modify the validation of empty cdroms to trigger only for
VIR_DOMAIN_DISK_MODEL_USB_STORAGE as with 'usb-bot' we can properly
emulate a cdrom.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The helper sets the 'attached' property of the 'usb-bot' device to true,
which will be used on the hotplug code path.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
While the 'usb-storage' based disks use the USB address directly, with
'usb-bot' the USB address is on the "controller" part of the device and
the 'scsi-hd/cd' device will use a 'drive' address from qemu's PoV.
Since we do not want to expose the 'usb-bot' as explicit controller
to preserve compatibility with existing configs we plan to upgrade
implement the formatter for 'drive' address when the "diskbus" property
is VIR_DOMAIN_DISK_BUS_USB.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
While 'usb-bot' and 'usb-storage' are ABI and migration compatible for
disks it's not the case for cdroms. When migrating from a new config
using 'usb-bot' to an older daemon which would use 'usb-storage' the
guest os will get I/O errors.
Thus we must properly fill in models for 'usb' disks so that cdroms can
be handled properly.
When parsing XML fill in the models and drop the appropriate models when
formatting migratable XML.
The logic is explained in comments in the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Historically libvirt specified 'usb-storage' as driver for USB disks.
This though combined with '-blockdev' doesn't properly configure the
device to look like CDROM for <disk type='cdrom'>.
'usb-bot' acts like a controler and allows explicitly connecting a
-device to it.
In qemu the devices share implementation so they are effectively
identical and can be used interchangably. There is a difference in how
the storage device itself (the SCSI part) looks when configured properly
as CDROM which is unfortunately not compatible/interchangable.
As this is effectively a bugfix we'll be fixing the behaviour for the
default configuration. The possibility to explicitly set the model is
added as a possibility for working around possible problems if they'd
appear.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The QEMU_CAPS_DEVICE_USB_BOT device can be compiled out but
realistically it makes no sense to do it thus also makes no sense to
have another variant of input data for it.
Add another invocation of "disk-usb-device" clearing QEMU_CAPS_DEVICE_USB_BOT
to show the fallback code paths.
Also add "ABI_UPDATE" version for the two cases above as the ABI of
usb-bot cdrom is not migration-compatible and we'll be wanting to update
to the fixed configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
usb-bot is supported by all supported QEMU versions; it is present since
1.4.0 and libvirt supports 4.2.0 or later.
Add a capability just in case USB_STORAGE_BOT is disabled when building
QEMU.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The 'removable' property is tested for 'usb' and 'scsi' disks. The test
case for 'usb' disks already has another test case for this, so add
testing of 'removable' SCSI disks into the 'disk-scsi' case and remove
the 'disk-device-removable' case completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The test case is now redundant since 'disk-usb-device' case also tests
all cdrom configurations. Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add multiple USB disks to the definition testing a matrix of 'disk' and
'cdrom' <disk> elements with user-aliases, 'serial' and 'removable'
properties configured.
This patch also removes the 'ide' disk which is not related to what
we're testing here.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The qemu hotplug code parses the device with ABI updates enabled so
qemuhotplugtest ought to do the same.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The main XML parser code global initializer historically had a mutex
protecting it, and more recently uses a pthread_once. The RelaxNG
code, however, relies on two other global initializers that are
not thread safe, just relying on setting an integer "initialized"
flag.
Calling the relevant initializers from libvirt in a protected global
initializer will protect libvirt's own concurrent usage, however, it
cannot protect against other libraries loaded in process that might
be using libxml2's schema code. Fortunately:
* The chances of other loaded non-libvirt code using libxml is
relatively low
* The chances of other loaded non-libvirt code using the schema
validation / catalog functionality inside libxml is even
lower
* The chances of both libvirt and the non-libvirt usage having
their *1st* usage of libxml2 be concurrent is tiny
IOW, in practice, although our solution doesn't fully fix the thread
safety, it is good enough.
libxml2 should none the less still be fixed to make its global
initializers be thread safe without special actions by its API
consumers[1].
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/788
[1] https://gitlab.gnome.org/GNOME/libxml2/-/merge_requests/326
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduced by QEMU commit f864a3235ea1d1d714b3cde2d9a810ea6344a7b5
the presence of this attribute allows libvirt to specify the alias
of the AMDVI-PCI device explicitly.
(It was implicit before the introduction of this attribute)
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Check for the presence of the amd-iommu device, so we can conditionalize
probing for its properties.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Shifting bits into the sign bit is undefined behaviour in C although
both gcc and clang handle it as expected.
Since the value is used as unsigned convert it to unsigned int. For code
readability use 'if' statement instead of a ternary.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/785
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When a domain is being started, seclabels are generated for it.
This is handled in virSecurityManagerGenLabel() which can either
find pre-existing seclabel in domain def or generate a new one.
At any rate, domainGenSecurityLabel() callback is called and if
it fails then the seclabel is removed from domain definition
using VIR_DELETE_ELEMENT(). While this shrinks down the seclabels
array, it does not free individual item. It has to be freed
manually.
80 bytes in 2 blocks are definitely lost in loss record 1,359 of 1,876
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F19B29: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8200.5)
by 0x49E4953: virSecurityLabelDefNew (virseclabel.c:59)
by 0x4BDE0A4: virSecurityManagerGenLabel (security_manager.c:638)
by 0xBA029B7: qemuProcessPrepareDomain (qemu_process.c:6760)
by 0xBA07DF2: qemuProcessStart (qemu_process.c:8369)
by 0xB93DAC0: qemuDomainObjStart (qemu_driver.c:6371)
by 0xB93DE08: qemuDomainCreateWithFlags (qemu_driver.c:6420)
by 0xB93DE86: qemuDomainCreate (qemu_driver.c:6438)
by 0x4CECEA8: virDomainCreate (libvirt-domain.c:7142)
Now, you might think this may lead to a double free, because
@seclabel is freed under the 'cleanup' label (if @generated is
true). But if @generated is true, then just before calling the
callback there's VIR_APPEND_ELEMENT() which clears @seclabel out
turning the free under 'cleanup' label into a NOP.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In my previous commit of v11.0.0-rc1~115 I've made QEMU driver
implementation for virDomainGetXMLDesc() (qemuDomainGetXMLDesc())
acquire QERY job. See its commit message for more info. But this
unfortunately broke apps witch fetch domain XML for incoming
migration (like virt-manager). The reason is that for incoming
migration the VIR_ASYNC_JOB_MIGRATION_IN async job is set, but
the mask of allowed synchronous jobs is empty (because QEMU can't
talk on monitor really). This makes virDomainObjBeginJob() fail
which in turn makes qemuDomainGetXMLDesc() fail too.
It makes sense for qemuDomainGetXMLDesc() to acquire the job
(e.g. so that it's coherent with another thread that might be in
the middle of a MODIFY job). But failure to dump XML may be
treated as broken daemon (e.g. virt-manager does so).
Therefore, still try to acquire the QUERY job (if job mask
permits it) but, do not treat failure as an error.
Fixes: 6cc93bf288
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2369243
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Add new URI parameter which allows for using non-system CA certificates
to verify remote peers.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The new condition allows waiting for the guest agent to show up, which
usually means that the guest has booted enough to respond to external
stimuli.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The new command is meant as syntax sugar for event handling which blocks
virsh until the requested state condition is reached.
The initial implementation adds a condition 'domain-inactive' returning
if the domain is/becomes inactive for whatever reason.
This command is useful for simple scripts e.g. for debugging libvirt
when it allows responding to target state in shell without the need to
fuss too much with polling or writing handlers around 'virsh event'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a new handler callback for command handlers which will want to
return more than just EXIT_SUCCESS/EXIT_FAILURE.
The new handler allows returning integers. Any negative values are
converted to EXIT_FAILURE, other values are returned as reported in
cases where we forward the command state (non-interactive usage) as
return value of the virt shell program.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently the handler functions in the virt shells return only a boolean
signalling if the command was successful or not. In preparation for a
command which will want to return another value (timeout) convert
vshCommand run to actually return the requested exit code instead and
document the conversion from boolean.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Successful return from 'virConnectDomainEventDeregisterAny' does not
guarantee that there aren't still in-progress events being handled by
the callbacks. Since 'cmdEvent' passes in a slice from an array as the
private data of the callbacks, we must ensure that the array stays in
scope (it's auto-freed) for the whole time there are possible callbacks
being executed.
While in practice this doesn't happen as the callbacks are usually quick
enough to finish while unregistering stuff, placing a 'sleep(1)' into
e.g. 'virshEventLifecyclePrint' and starting a domain results in crash
of virsh with the following backtrace:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00005557b5cfd343 in virshEventPrintf (data=data@entry=0x5557db9619b0, fmt=fmt@entry=0x5557b5d5e527 "%s") at ../../../libvirt/tools/virsh-domain-event.c:252
Thread 2 (Thread 0x7f59a54b7d00 (LWP 2097121)):
#0 0x00007f59a6cadbf9 in __futex_abstimed_wait_common () at /lib64/libc.so.6
#1 0x00007f59a6cb2cf3 in __pthread_clockjoin_ex () at /lib64/libc.so.6
#2 0x00005557b5cd57f6 in virshDeinit (ctl=0x7ffc7b615140) at ../../../libvirt/tools/virsh.c:408
#3 0x00005557b5cd5391 in main (argc=<optimized out>, argv=<optimized out>) at ../../../libvirt/tools/virsh.c:932
Thread 1 (Thread 0x7f59a51a66c0 (LWP 2097122)):
#0 0x00005557b5cfd343 in virshEventPrintf (data=data@entry=0x5557db9619b0, fmt=fmt@entry=0x5557b5d5e527 "%s") at ../../../libvirt/tools/virsh-domain-event.c:252
#1 0x00005557b5cffa10 in virshEventPrint (data=0x5557db9619b0, buf=0x7f59a51a55c0) at ../../../libvirt/tools/virsh-domain-event.c:290
#2 virshEventLifecyclePrint (conn=<optimized out>, dom=<optimized out>, event=<optimized out>, detail=<optimized out>, opaque=0x5557db9619b0) at ../../../libvirt/
[snipped]
From the backtrace you can see that the 'main()' thread is already
shutting down virsh, which means that 'cmdEvent' terminated and the
private data was freed. The event loop thread is still execing the
callback which accesses the data.
To fix this add a condition and wait on all of the callbacks to be
unregistered first (their private data freeing function will be called).
This bug was observed when I've copied the event code for a new virsh
command which had a bit more involved callbacks.
Fixes: 99fa96c390
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add the automatic cleanup handler as well as static initializer to allow
simple stack allocated conditions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This makes it very convenient to declare a mutex on stack along with the
VIR_MUTEX_INITIALIZE macro without the need to have complex cleanup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The mirroring job clears the destination to ensure that the guest
visible disk contents are identical to the state on the source. The
image itself is kept sparse only when the disk 'discard' option is set
to 'unmap' (Also the disks would eventually desparsify itself anyways
with disabled discards). Note it in the docs for the user.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Acked-by: Eric Blake <eblake@redhat.com>
QEMU clears the images even when sparse mode is required so asking the
users to do so is not needed. Remove the docs.
This reverts commit 332ee4931a
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Acked-by: Eric Blake <eblake@redhat.com>
Add a note that the user/group can be overriden or relabelling disabled
using per-vm/disk <seclabel> elements instead of disabling it globally.
Add a note that read-only image labels are not restored.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/512
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bug reports from automated tools and AI agents are time consuming to
triage and have poor signal/noise ratio. Set strong expectations for
any reporters using such tools, in a (likely doomed) attempt to stem
the flow of poor quality reports.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Having a blank line between the term and its definition prevents the RST
to HTML convertor highlighting 'pkipath' correctly.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We no longer check for the presence of the commands included
in these packages at build time.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We've recently stopped checking for the presence of various
commands at build time, which means that we no longer need
to have the corresponding packages installed in the build
environment.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
daemon-common should have always depended on kmod, since
there are various situations in which a module (un)load might
be triggered by a driver.
For the util-linux dependency, we're simply adjusting the
comment to match reality.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is a separate commit for review ease, but who's really going to use
a libvirt with this patch in and the actual functionality missing, that
ain't gonna happen, right?
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Honglei Wang <honglei.wang@smartx.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The "nvme" device is the controller and "nvme-ns" are the
namespaces (individual disks) plugged into it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Honglei Wang <honglei.wang@smartx.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
NVMe disks are essentially a namespace of an NVMe controller, but to
make it easier for the users to just add a disk, the necessary details
like adding the proper controller, setting the serial number for the
controller based on the disk, are done automatically.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Honglei Wang <honglei.wang@smartx.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Same as for the SCSI controller, but this time for NVMe, will be used
later to do some post parse modifications.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We do not guarantee that the disk names will be the same in guest as
they are in the XML, but that should not stop us from trying to be
consistent with the naming. And since we use the same naming as the
linux kernel does, let's stick with it with nvme drives too.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
accel->cpuModels field might be NULL if QEMU does not return CPU models.
The following backtrace is observed in such cases:
0 virQEMUCapsProbeQMPCPUDefinitions (qemuCaps=qemuCaps@entry=0x7f1890003ae0, accel=accel@entry=0x7f1890003c10, mon=mon@entry=0x7f1890005270)
at ../src/qemu/qemu_capabilities.c:3091
1 0x00007f18b42fa7b1 in virQEMUCapsInitQMPMonitor (qemuCaps=qemuCaps@entry=0x7f1890003ae0, mon=0x7f1890005270) at ../src/qemu/qemu_capabilities.c:5746
2 0x00007f18b42fafaf in virQEMUCapsInitQMPSingle (qemuCaps=qemuCaps@entry=0x7f1890003ae0, libDir=libDir@entry=0x7f186c1e70f0 "/var/lib/libvirt/qemu",
runUid=runUid@entry=955, runGid=runGid@entry=955, onlyTCG=onlyTCG@entry=false) at ../src/qemu/qemu_capabilities.c:5832
3 0x00007f18b42fb1a5 in virQEMUCapsInitQMP (qemuCaps=0x7f1890003ae0, libDir=0x7f186c1e70f0 "/var/lib/libvirt/qemu", runUid=955, runGid=955)
at ../src/qemu/qemu_capabilities.c:5848
4 virQEMUCapsNewForBinaryInternal (hostArch=VIR_ARCH_X86_64, binary=binary@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha",
libDir=0x7f186c1e70f0 "/var/lib/libvirt/qemu", runUid=955, runGid=955,
hostCPUSignature=0x7f186c1e9f20 "AuthenticAMD, AMD Ryzen 9 7950X 16-Core Processor, family: 25, model: 97, stepping: 2", microcodeVersion=174068233,
kernelVersion=0x7f186c194200 "6.14.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 29 May 2025 21:42:15 +0000", cpuData=0x7f186c1ea490)
at ../src/qemu/qemu_capabilities.c:5907
5 0x00007f18b42fb4c9 in virQEMUCapsNewData (binary=0x7f1868002fc0 "/usr/bin/qemu-system-alpha", privData=0x7f186c194280)
at ../src/qemu/qemu_capabilities.c:5942
6 0x00007f18bd42d302 in virFileCacheNewData (cache=0x7f186c193730, name=0x7f1868002fc0 "/usr/bin/qemu-system-alpha") at ../src/util/virfilecache.c:206
7 virFileCacheValidate (cache=cache@entry=0x7f186c193730, name=name@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha", data=data@entry=0x7f18b67c37c0)
at ../src/util/virfilecache.c:269
8 0x00007f18bd42d5b8 in virFileCacheLookup (cache=cache@entry=0x7f186c193730, name=name@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha")
at ../src/util/virfilecache.c:301
9 0x00007f18b42fb679 in virQEMUCapsCacheLookup (cache=cache@entry=0x7f186c193730, binary=binary@entry=0x7f1868002fc0 "/usr/bin/qemu-system-alpha")
at ../src/qemu/qemu_capabilities.c:6036
10 0x00007f18b42fb785 in virQEMUCapsInitGuest (caps=<optimized out>, cache=<optimized out>, hostarch=VIR_ARCH_X86_64, guestarch=VIR_ARCH_ALPHA)
at ../src/qemu/qemu_capabilities.c:1037
11 virQEMUCapsInit (cache=0x7f186c193730) at ../src/qemu/qemu_capabilities.c:1229
12 0x00007f18b431d311 in virQEMUDriverCreateCapabilities (driver=driver@entry=0x7f186c01f410) at ../src/qemu/qemu_conf.c:1553
13 0x00007f18b431d663 in virQEMUDriverGetCapabilities (driver=0x7f186c01f410, refresh=<optimized out>) at ../src/qemu/qemu_conf.c:1623
14 0x00007f18b435e3e4 in qemuConnectGetVersion (conn=<optimized out>, version=0x7f18b67c39b0) at ../src/qemu/qemu_driver.c:1492
15 0x00007f18bd69c5e8 in virConnectGetVersion (conn=0x55bc5f4cda20, hvVer=hvVer@entry=0x7f18b67c39b0) at ../src/libvirt-host.c:201
16 0x000055bc34ef3627 in remoteDispatchConnectGetVersion (server=0x55bc5f4b93f0, msg=0x55bc5f4cdf60, client=0x55bc5f4c66d0, rerr=0x7f18b67c3a80,
ret=0x55bc5f4b8670) at src/remote/remote_daemon_dispatch_stubs.h:1265
17 remoteDispatchConnectGetVersionHelper (server=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60, rerr=0x7f18b67c3a80, args=0x0, ret=0x55bc5f4b8670)
at src/remote/remote_daemon_dispatch_stubs.h:1247
18 0x00007f18bd5506da in virNetServerProgramDispatchCall (prog=0x55bc5f4cae90, server=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60)
at ../src/rpc/virnetserverprogram.c:423
19 virNetServerProgramDispatch (prog=0x55bc5f4cae90, server=server@entry=0x55bc5f4b93f0, client=0x55bc5f4c66d0, msg=0x55bc5f4cdf60)
at ../src/rpc/virnetserverprogram.c:299
20 0x00007f18bd556c32 in virNetServerProcessMsg (srv=srv@entry=0x55bc5f4b93f0, client=<optimized out>, prog=<optimized out>, msg=<optimized out>)
at ../src/rpc/virnetserver.c:135
21 0x00007f18bd556f77 in virNetServerHandleJob (jobOpaque=0x55bc5f4d2bb0, opaque=0x55bc5f4b93f0) at ../src/rpc/virnetserver.c:155
22 0x00007f18bd47dd19 in virThreadPoolWorker (opaque=<optimized out>) at ../src/util/virthreadpool.c:164
23 0x00007f18bd47d253 in virThreadHelper (data=0x55bc5f4b7810) at ../src/util/virthread.c:256
24 0x00007f18bce117eb in start_thread (arg=<optimized out>) at pthread_create.c:448
25 0x00007f18bce9518c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Signed-off-by: anonymix007 <anonymix007@users.noreply.github.com>
These mirrors no longer exist, they're just straight up
redirects to GitLab now.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We use the same format for GitLab and libvirt.org, but not
for GitHub.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Inside of libxlMakeDomainCapabilities() there are some functions
called and basically all of them never return anything but zero
(indicating success). Yet, they are called in a fashion that
suggests otherwise. Turn those functions into void and drop
checks for their retvals.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extend domain capabilities with information about the supported console
device types.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend domain capabilities with information about the supported console
device types.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend domain capabilities to report the NMDM console support.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, domain capabilities do not include information about the
supported console device types. While most of the drivers support
'pty' console type, it's not the case for bhyve. Without this
information, management software cannot always generate compatible
domain configuration.
To address that, extend domain capabilities like that:
<devices>
...
<console supported='yes'>
<enum name='type'>
<value>pty</value>
<value>type2</value>
...
</enum>
</console>
...
</devices>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Previously, the 'desktop' graphics configuration contained the
'fullscreen' option which was never used, removed the unused option.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously, the RDP graphics definition parsing were implemented by
string parsing, the virDomainGraphicsDefParseXMLRDP function is
refactored to use the appropriate virXMLProp* utility functions.
Overall parsing logic was not changed and results the same output as
before.
Moreover, 'replaceUser' and 'mutliUser' params type was changed from
bool to tristate type, to avoid unnecessary type convertions.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously, the fullscreen option were parsed as a tristate but stored
as a bool type, changed the fullscreen option type to tristate bool to
avoid unnecessary type convertions.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously, the VNC graphics definition parsing were implemented by
string parsing, the virDomainGraphicsDefParseXMLVNC was refactored
to use the appropriate virXMLProp* utility functions. Overall
parsing logic was not changed and results the same output as before.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU can't really do live dumps of guest memory. It's because
inside of dump_init() the vm_stop() is called basically
unconditionally (the only condition is whether vCPUs are
running). Hence, there is no way for us to do live dumps and thus
honor VIR_DUMP_LIVE flag. Instead of silently pretending the flag
works, reject it with appropriate error message.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/646
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Attempting to set MTU for network types which don't actually use the
network device on the host results in a failure. The 'mtu' property is
also used e.g. for the 'host_mtu' property of e.g. 'virtio-net-pci'
which is applied even in vhost-user mode.
Use the existing switch which selects devices without a network device
backend on the host side and skip setting the MTU.
Tested by running 'passt' in vhost-user mode manually:
passt -f --vhost-user -s /tmp/vh.sock
and the following XML:
<interface type="vhostuser">
<mac address="52:54:00:3d:91:97"/>
<source type="unix" path="/tmp/vh.sock" mode="client"/>
<model type="virtio"/>
<mtu size="9999"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
</interface>
The OS in the guest reports MTU 9999.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/717
Closes: https://gitlab.com/libvirt/libvirt/-/issues/192
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The generated code which parses the data from XML in
esxVI_LookupDatastoreContentByDatastoreName can fill the 'folderPath'
property with NULL if it were missing from the input XML. While this is
not likely when talking to esx it is a possible outcome. Skipp NULL
results.
All other code paths already ensure that the function is not called with
NULL.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/776
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since the 'compat' field is set based on qcow2 features it belongs to
the qcow2 code rather than to the main metadata probing function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refactor qcow2GetExtensions to parse everything at once and directly
assign it into fields in the parsed virStorageSource.
This removes the need for qcow2GetDataFile as it will be parsed
directly.
The patch also simplifies the juggling of variables which was needed to
parse the backing file format, when it was passed via pointer in
argument.
qcow2GetExtensions is now invoked on qcow2 images so we can remove the
version check for qcow(v1) images.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Parse qcow2 feature flags from qcow2GetImageSpecific. To achieve that
qcow2GetFeatures is refactored to take virStorageSource directly and
fill the data. To avoid the need to pass 'format' the parsing of the
qcow2 version is changed to access the offset directly (same as in
qcow2GetExtensions)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the two functions to where they will be used. Subsequent patches
will refactor the control flow so that they will no longer be declared
ahead of time. Moving them in a separate patch will make the changes in
the refactor more clear to see.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the cluster size parser into the image specific code for qcow2,
which will later allow us to remove the callback for cluster size which
is not used by any other format.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Change qcowXGetBackingStore to use the new function prototype which
fills virStorageSource directly. Convert the copying of the backing file
string from 'g_new0' + 'memcpy' to 'g_strndup' as we treat it as a
string.
Introduce qcowGetImageSpecific (as a wrapper for qcowXGetBackingStore)
and qcow2GetImageSpecific. The latter of the two will be used to collect
all the qcow2-specific code later on, but for now it just parses the
backing store and the format.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Change to the new function prototype and adjust the code to fill the
fields in virStorageSource directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Change to the new function prototype and adjust the code to fill the
fields in virStorageSource directly.
The code also converts the copying of the backing file string from
'g_new0' + 'memcpy' to 'g_strndup' as we treat it as a string later on.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename the function, adjust parameters and fix the code to fill the
virStorageSource fields directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The callbacks getting just some fields are not flexible and in some
cases cause the metadata to be probed multiple times.
Add a callback that will pass the whole virStorageSource struct being
probed so that the code can be written more efficiently.
As a first step we add just the callback. The specific format helpers
will be refactored and subsequently all the other callbacks will be
removed.
To simplify the refactors that will convert all the code to the new
callbacks the new callback is placed first but the calls to cleanup
previous metadata are moved before it. They'll be removed once the
refactors are complete together with the other callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add change block tracking bitmaps to some of the qcow2 images, to ensure
that they work with our qcow2 header parser even when we don't parse
them ourselves.
The existing images were modified by running:
$ qemu-img bitmap --add qcow2_qcow2-qcow2_qcow2-auto.qcow2 testbitmap
$ qemu-img bitmap --add qcow2datafile-datafile.qcow2 testbitmap
$ qemu-img bitmap --add datafile.qcow2 testbitmap
in tests/virstoragetestdata/images/.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are 3 bugs in the qcow2 header extension parser:
1) Header extension padding not taken into account
Per qcow2 documentation (qemu.git/docs/interop/qcow2.txt, also now
mirrored in the comment explaining the parser) each header extension
entry is padded to a multiple of 8 bytes.
Our parser didn't take the padding into account and advanced the
current offset only by the 'length', which corresponds to the length
of the data.
This meant that in vast majority of cases only the first extension
would be parsed correctly. For any other one we'd try to fetch the
magic and length from wrong place.
Luckily this wasn't a problem for most of the almost 15 years this bug
existed as we only cared about the backing file format string header
which was always stored first by qemu.
It is now a problem in the very specific case when a qcow2 image has a
'data-file' and also a backing store with format. In such case we'd
parse the backing store format properly as it's the first header and
'data-file' being the second would be skipped.
The buffer bounds checks were correct so we didn't violate any memory
boundaries.
2) Integer underflow in calculation of end of header extension block
If the image doesn't have a backing image, the 'backing_file_offset'
qcow2 header field is 0. We use that value as 'extensions_end' which
is used in the while loop to parse the extension entries.
The check was done as "offset < (extensions_end - 8)", thus it
unreflows when there's no filename.
The design of the loop prevented anything bad from happening though.
3) Off-by-one when determining end of header extension block
The aforementioned end of extension check above also has an off-by-one
error as it allowed another loop if more than 8 bytes were available.
Now the termination entry has data length of 0 bytes so we'd not be
able to properly process that one.
This wasn't a problem either as for now there's just the terminator
having 0 byte length.
This patch improves documentation by quoting the qcow2 interoperability
document and adjusts the loop condition and length handling to comply
with the specs.
Interestingly we also had a test case for this specific scenario but the
expected test output was wrong.
Fixes: a93402d48b
Resolves: https://issues.redhat.com/browse/RHEL-93775
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the 'dataFileRaw' field to the main block as it's based on the data
in the qcow2 header same as 'backingStoreRaw'.
Indent and annotate the corresponding dataFile block to show where it
belongs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add debug statements which were useful in figuring out bugs in the qcow2
extension parser.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the rest of the RDP graphics validation code to
qemuValidateDomainDeviceDefRDPGraphics together with the rest of the
validation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Both the 'replaceUser' and 'multiUser' field are already validated in
qemuValidateDomainDeviceDefRDPGraphics.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move the checks from 'qemuProcessStartValidateGraphics' to the
correspodning graphics validation functions in qemu_validate.c:
- qemuValidateDomainDeviceDefSPICEGraphics
- qemuValidateDomainDeviceDefVNCGraphics
- qemuValidateDomainDeviceDefRDPGraphics
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Remove the config file handling for the config options we no longer use.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
qemu-5.2 dropped support for VxHS. As we now require at least qemu-6.2,
the qemu.conf option for setting up TLS for VxHS are no longer used.
Document them as such.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
qemu-5.2 dropped support for the 'vxhs' protocol. We require qemu-5.2
since commit ce48d584cc and thus the block code for vxhs is now dead.
Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move the check forbidding VXHS disks and checking the NVME backend
capability to the validation code.
Remove the now unused qemuProcessStartValidateDisks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move the validation of TFTP and NFS into a new switch statement which
will be used for validating also other protocol config in the future.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The function is called by virFileIsSharedFSOverride which is not Linux
specific and thus building on anything but Linux failes.
Fixes: 94fb348d67
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The code was separated from virFileIsSharedFSType which is Linux-only,
but virFileGetExistingParent is also called from
virFileIsSharedFSOverride which is OS independent. Thus we can't use
statfs. Let's use virFileExists (access) instead, we were not interested
in anything but success/failure from statfs anyway.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit v11.0.0-162-gf2023e8018 added path canonicalization to
virFileIsSharedFSOverride to make sure we can properly match shared
filesystem override paths which include symlinks. But
virFileCanonicalizePath only works on existing paths, while
virFileIsSharedFSOverride may be called on paths that do not exist yet.
Matching paths against overrides has always worked even for nonexistent
paths. To fix the regression we need to first get the longest existing
sub-path and canonicalize only this part and use the result for
searching in overrides. Clearly any portion of the path we dynamically
create is not going to end up on a different filesystem to what the
parent directory is stored in. So checking just the existing parent is
enough.
https://issues.redhat.com/browse/RHEL-86592
Fixes: f2023e8018
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code from virFileIsSharedFSType which finds the longest existing
path for a given input is separated into a new helper so that it can be
reused elsewhere.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On most platforms virFileCanonicalizePath is implemented using
realpath(), which only works on existing paths.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The VIR_ERR_NO_SUPPORT error is supposed to be used for unsupported
driver APIs. It is incorrectly used when swtpm does not support
migration with shared storage resulting in a rather strange error
message:
this function is not supported by the connection driver: the running
swtpm does not support migration with shared storage
The correct VIR_ERR_OPERATION_UNSUPPORTED error code provides a much
better message:
Operation not supported: the running swtpm does not support
migration with shared storage
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since commit 28a0621528 (released in 11.2.0) resuming a failed
post-copy migration calls qemuProcessIncomingDefNew with fd == NULL
rather than -1. The function does not expect to be called with NULL file
descriptor and tries to dereference it causing virtqemud on the
destination host to crash.
Fixes: 28a0621528
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Explain what the individual settings actually result in. The changes
are based on the paraprhase of qemu documentation which in
'qemu-options.hx' states:
``werror=action,rerror=action``
Specify which action to take on write and read errors. Valid
actions are: "ignore" (ignore the error and try to continue),
"stop" (pause QEMU), "report" (report the error to the guest),
"enospc" (pause QEMU only if the host disk is full; report the
error to the guest otherwise). The default setting is
``werror=enospc`` and ``rerror=report``.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/138
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refuse to use floppy devices if qemu doesn't support them. Reflect that
also in capabilities. Both of the above is achieved by checking for the
QEMU_CAPS_BUS_FLOPPY in qemuDomainMachineSupportsFloppy.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce a common capability for support of floppy devices by qemu.
Floppy support can be compiled out ('FDC', 'FDC_ISA', 'FDC_SYSBUS' qemu
Kconfig options) and also isn't supported by all architectures. Add a
capability that will check for 'isa-fdc' and 'sysbus-fdc' devices and
signal that given qemu supports the floppy bus.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move the validation from qemuProcessStartValidateDisks to
qemuValidateDomainDeviceDefDiskFrontend and adjust the test case which
now fails a bit earlier, thus no output XML is needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a helper that will collect the logic for determinin whether a VM
supports floppy disks.
Use it in the capabilities code and when validating the VM definition at
startup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
While we were trying to decrease stack usage of some functions,
in v9.8.0-rc1~217 we introduced a couple of internal blocks to
the aiforaf() and declared some variables inside those blocks
hoping the compiler will reuse the stack for each block. While in
general this might be a good strategy, specifically in case of
NSS_NAME(gethostbyname2) this is a terrible thing to do.
Problem is, NSS_NAME(gethostbyname2) is given a caller allocated
buffer and an address of a pointer where the resolved address is
stored. And you've probably guessed it already: upon successful
return, the pointer is set to point somewhere inside the buffer.
Now, if the buffer doesn't live long enough, which in our case it
does not (since it was left in the previous block), we should
refrain from dereferencing the resolved pointer.
Just allocate the buffer on the heap.
Fixes: 9e5f2fe402
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
So far, inside of the ERROR() macro there's pretty large buffer
allocated on the stack (for use by strerror_r()). Problem is,
with our current stack size limit of 2048 bytes we may come
pretty close to the limit or even overshoot it, e.g. in aiforaf()
where the function itself declares another stack allocated buffer
1024 bytes long.
Just allocate the buffer dynamically.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After previous cleanup, some labels were rendered pointless. Drop
them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
While we do not want the nss plugin to link with anything but
necessary libs (libc and libjson-c) it can benefit from automatic
memory freeing. Instead of inventing macros with new name for
them, lets stick with g_autofree and g_steal_pointer() which we
are used to from the rest of the code. Borrow and simplify
definitions for these macros then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
There are two places where gai_strerror() is called but neither
of them includes all necessary header files as documented in its
manpage. Fortunately, both calls occur in ERROR() macro which by
default does nothing - hence we don't see any compilation errors.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Inside of findMACsFromJSON(), the retval of
json_object_array_length() is stored in a variable that's type of
int. But the function is declared to return size_t:
/usr/include/json-c/json_object.h:JSON_EXPORT size_t json_object_array_length(const struct json_object *obj);
Fix the type of the local variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This patch adds POWER11 CPU host-model support in libvirt's ppc64
CPU driver. With this addition, guests using CPU mode 'host-model'
can specify POWER11 as the CPU model and have libvirt handle it
correctly.
With this change, libvirt can generate correct QEMU command line using
`-machine ... max-cpu-compat=power11` when a POWER11 host-model guest is
defined. This aligns with the QEMU support for POWER11 compatibility mode
starting from version 10.0.0.
Test coverage includes:
- XML validation tests for POWER11 host model
- Negative test for invalid compatibility on POWER10 hosts
- Command line generation tests for POWER11 guests
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com>
Tested-By: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Reviewed-By: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add support for the POWER11 CPU model in libvirt ppc64 CPU map. This
allows libvirt to recognize and handle guests that specify POWER11 as
the target CPU model when running on recent Power systems supporting
this architecture.
The addition includes:
- A new src/cpu_map/ppc64_POWER11.xml definition file describing the
features and flags for POWER11 CPUs.
- Updates to src/cpu_map/index.xml and build system (meson) to include
the new model.
- Test updates to qemucapabilitiesdata and qemuxmlconfdata to reflect
the presence of POWER11 in supported CPU models.
- Adjustments to existing test XMLs to fix CPU model expectations
and avoid mismatches during validation against QEMU output.
With this change, users can specify <model>POWER11</model> in guest CPU
configuration and have libvirt map it correctly to the corresponding
QEMU CPU model and capabilities.
Tested with:
- QEMU 10.0.0 on POWER11 host system
- Validated with updated domain capabilities and qemu capabilities tests
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com>
Tested-By: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Reviewed-By: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add the qemu test capabilities xml and reply files for
QEMU v10.0.0 on ppc64. A QEMU v10.0.0 was used for generating
this data.The tests with the 'latest' suffix, which expect
the latest available CPU version from the capabilities XML,
are bumped up to the latest CPU version.
Notable changes:
- new pseries-10 machine type
- old machine types (2.7) dropped
- new CPU models power11 added
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 140ff3c514 ("tests: qemuhotplugtest: Fix arch-specific parts of
'ppc64' test XMLs") hardcoded the CPU model as POWER9 in the test result
XMLs. However, this value actually reflects the host CPU model detected
at build or test time, and can vary depending on the machine where the
tests run.
As newer POWER CPU models (e.g., POWER10, POWER11) become common, this
requires continuous updates to the test result files to match the CPU
version detected on the host. This adds unnecessary maintenance effort.
Fix this by updating the test source domain XMLs to specify POWER9 (or
any fixed version) as the CPU model. This ensures the test result files
stay stable and do not require updates every time a newer CPU is used on
the host system.
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Support for the pseries-2.7 machine type in QEMU was officially removed in
version 9.2 with qemu commit 445d3facffe8 ("ppc/spapr: remove deprecated
machine pseries-2.7"). Instead of removing related tests, they are now pinned
to the latest available capabilities version 7.0.0 to ensure continued
functionality where applicable.
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a couple of examples of the explicit NVRAM configuration, and also
an automatic configuration, along with `<os firmware="efi">`.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For quite some time now FreeBSD provides its own version of the grep(1)
tool, and the GNU grep from the ports collection is available as
ggrep(1). So remove the detection code and just request ggrep.
Signed-off-by: Alexey Dokuchaev <danfe@FreeBSD.org>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The argument was always ignored by qemu [1], as of qemu-10.1 it will be
deprecated. As it was always unused/ignored we can drop it without any
extra logic.
[1] qemu docs state:
3. The user Monitor's "detach" argument is invalid in QMP and
should not be used.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The only caller always passes 'true'. We also don't want to ever use the
blocking variant as it blocks the whole monitor until dump finishes.
Hardcode it to 'true' in the monitor code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Few arguments were missing the 'vshCompletePathLocalExisting' completer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Few outstanding arguments were not marked with 'virshCompleteEmpty'
completer despite the fact that we can't provide any reasonable
suggestion, e.g. for the new description of a domain or for the launch
secret.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Few outstanding arguments were not marked with completers
completer despite the fact that we can't provide any reasonable
suggestion (e.g 'echo' or 'complete' commands) or where we want to
complete local path ( 'cd' ).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The helper methods as well as the empty completers can be useful also in
other virt shells; extract the code and rename the functions
appropriately.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Marking more tests with JSON_MODELS_REQUIRED as these tests fail if QEMU is
disabled, typically when running tests on FreeBSD or macOS systems.
Signed-off-by: Jaroslav Suchanek <jsuchane@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add the bhyveDomainDefValidate() validation which currently checks
whether the requested NVRAM is supported.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend bhyveFirmwareFillDomain() so that when we find the default edk2
firmware, also look for its matching template file, and use it as a
nvramTemplate if found.
Extend bhyvexml2argvtest to verify various NVRAM configurations.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, bhyve bootrom specification looks like this:
bhyve ... -l bootrom,/path/to/firmware.fd
In addition to that, it supports specifying the VARS files using:
-l bootrom,/path/to/firmware.fd,/path/to/my_domain_VARS.fd
Update virBhyveProcessBuildBhyveCmd() to include the VARS file if NVRAM
is specified in the domain XML.
Additionally, support copying this file from the specified template. To
do that, introduce the bhyveProcessPrepareHost() and related helpers.
They are currently not doing anything but NVRAM preparations, but should
be useful for other host-side related tasks in the future.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As a preparation for NVRAM support, introduce nvramDir configuration
item.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Log information (type, label, etc) about FDs passed to qemu via APIs
from this module.
This does "spill" the selinux library code into this module, but
acessing it via the security driver would require passing much more
context to this module. Since it's for logging only it can be easily
removed if necessary.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In case selinux is used on the host the socket passed to qemu needs to
be properly labelled. Add a hint to the example code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While I've actually implemented support for FD passing the NBD server
socket in eb768a556d I managed to misplace the hunk allowing the 'FD'
transport in the validation code, rendering the whole feature useless.
Fix the validation logic to make the feature usable.
Fixes: eb768a556d
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Assign local variables directly and use autofree for temproary ones.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The function can extract the value from @vm's private data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For now it's extracted as a temporary variable but in long term it ought
to be eliminated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor the function and all callees to use the driver config instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Make it obvious that the variable is used for internal snapshot
reversion by renaming it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Make it obvious that the variable is used for internal snapshot
reversion by renaming it. This is necessary mainly as the function
parameters are not documented, but makes it obvious also if they were.
We can also report the name of the sanpshot rather than a pointer that
says absolutely nothing to the reader.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Make it obvious that the variable is used for internal snapshot
reversion by renaming it. This is necessary mainly as the function
parameters are not documented, but makes it obvious also if they were.
We can also report the name of the sanpshot rather than a pointer that
says absolutely nothing to the reader.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After recent refactors that removed legacy way to revert snapshots we no
longer need to know the snapshot state during commandline build.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Only the internal snapshot code paths were able to handle transient
domains properly in case when startup of the process failed.
Unify the error paths on an 'error' label with proper handling.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Code paths which deal with stopping of the qemu process need extra
handling for transient definitions as they need to be removed from the
domain list when we'd be leaving them inactive.
In case of snapshot code it's on failure to revert a snapshot as we stop
the qemu process but the failure to revert may mean that the new process
will not be started.
I've observed this when I was fixing the recent bug in snapshot
reversion which left the domain in unusable state after failure to
revert:
$ virsh list foo
error: Requested operation is not valid: domain is not running
$ virsh undefine foo
error: Requested operation is not valid: cannot undefine transient domain
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The memory/device state of the VM for an internal snapshot is restored
by qemu itself via a QMP command and is taken from the qcow2 image, thus
we don't actually do any form of incoming migration.
Commit 5b324c0a73 which refactored the setup of the incoming
migration state didn't take the above into account and inadvertently
caused that qemu is being started with '-incoming defer' also when
libvirt would want to revert an internal snapshot.
Now when qemu expects incoming migration it doesn't activate the block
backends as that would cause locking problems and image inconsistency,
but also doesn't allow the use of the images. Since the block backends
are not activated qemu then thinks that they don't actually support
internal snapshots and reports:
error: operation failed: load of internal snapshot 'foo1' job failed: Device 'libvirt-1-format' is writable but does not support snapshots
Due to the above bug it's not possible to revert to internal snapshots
in libvirt-11.2 and libvirt-11.3.
Fixes: 5b324c0a73
Resolves: https://issues.redhat.com/browse/RHEL-88747
Closes: https://gitlab.com/libvirt/libvirt/-/issues/771
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The following build error is observed when the DEBUG_BUILD variable
is enabled in OpenEmbedded:
src/cpu/cpu_x86.c: In function 'cpuidSetLeaf4':
src/cpu/cpu_x86.c:2563:1: error: inlining failed in call to 'cpuidCall': function not considered for inlining [-Werror=inline]
2563 | cpuidCall(virCPUx86CPUID *cpuid)
| ^~~~~~~~~
Remove the 'inline' specifier to avoid the problem.
Reported-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
RHEL-8 is out of our support scope. The minimal version we aim to
support upstream is RHEL-9. Reflect this in the spec file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a pcihole64 test for the aarch64 virt machine that verifies the
value is propagated to the highmem-mmio-size virt machine parameter.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add support for generating QEMU command line with PCI high memory MMIO size:
- Add highmem-mmio-size to machine command line generation using
size conveyed through pcihole64
- Add validation for aarch64/virt machine type requirement
- Add capability check for QEMU support
This enables configuring the PCI high memory MMIO window size
for aarch64 virt machine types using the existing pcihole64
element.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add QEMU capability for PCI high memory MMIO size configuration:
- Add QEMU_CAPS_MACHINE_VIRT_HIGHMEM_MMIO_SIZE capability
- Add capability to virt machine properties
- Add highmem-mmio-size virt machine property to aarch64 qemu
10.0.0 capabilities
This allows detecting support for the highmem-mmio-size virt machine
property in QEMU.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Cloud Hypervisor supports virtio-rng devices and the configuration of
the randomness source (e.g. /dev/random or /dev/urandom).
This commit adds support for configuring the RNG device via libvirt for
the ch driver.
Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As advised by the GNU TLS, the caller should attempt again
if the gnutls_record_{recv,send} return EAGAIN or EINTR;
check the following link to view the details:
https://www.gnutls.org/manual/html_node/Data-transfer-and-termination.html
virNetClientSetTLSSession failed to handle EINTR/EGAIN,
though EGAIN seems like it ought to be unlikely given that
the caller waited for G_IO_IN.
Add the {repoll, retry} logic to handle EINTR/EGAIN that
may happen theoretically. This may reduce the likelihood
that the upper application receives the following error
message utmostly when it calls the virConnectOpenAuth API:
Unable to read TLS confirmation: Resource temporarily unavailable
Note that in order to fully avoid the mentioned problem, the
upper application should retry virConnectOpenAuth.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Hyman Huang <yong.huang@smartx.com>
There are couple of functions (virCHDomainPrepareHostdevPCI(),
qemuDomainPrepareHostdevPCI(),
virStorageBackendRBDSetAllocation(), virCommandHandshakeChild())
that are declared to return an integer, but in fact return a
boolean. This may lead to incorrect behaviour. Fix their retvals.
This diff was generated using the following semantic patch:
@@
identifier foo;
@@
int foo(...) {
<+...
(
- return true;
+ return 0;
|
- return false;
+ return -1;
)
...+>
}
Each function and its callers were then inspected to see what
retvals are expected.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The virshBuildPoolXML() function is declared to return an int but
in fact its return type is a boolean. Even its both callers
(cmdPoolCreateAs() and cmdPoolDefineAs()) treat its retval as a
boolean. Switch the return type from integer to boolean.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The virNetDevVlanEqual() function is declared to return an int
but in fact its return type is a boolean. Even its only caller
(qemuDomainChangeNet()) treats its retval as a boolean. Switch
the return type from integer to boolean.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Inside of storage_backend.c there are two implementations of
volStorageBackendRBDUseFastDiff() function: one when librbd is
new enough and one when it isn't. The former returns a bool, but
the latter is declared to return an int despite it returning a
boolean. Fix the latter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuDomainHasHotpluggableStartupVcpus() function is declared
to return an int but in fact its return type is a boolean. Even
its only caller (qemuProcessLaunch()) treats its retval as a
boolean. Switch the return type from integer to boolean.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The virNWFilterCanApplyBasicRules() callback returns an int but
in fact its return type is a boolean. Even its only
implementation (ebiptablesCanApplyBasicRules()) returns a
boolean. Switch the return type from integer to boolean.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Inside of storage_backend_rbd.c there are two implementations of
virStorageBackendRBDSetAllocation(). One reports an error on
failure, so the stub implementation should report an error too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
While the queue count itself is not a guest visible property, libvirt
uses it to calculate the 'vectors' property of the 'virtio-net' device
which is ABI.
Since we don't expose control of 'vectors' explicitly, consider 'queues'
ABI.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Due to a logic bug the error message mentioning multi queue operation
would be emitted also when a single queue would be opened on an
externally managed tap device.
Adjust the condition to trigger only when multiple queues are in use.
Fixes: f6fb097e11
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If either of the autostart settings is enabled the VM will be
autostarted. Attempt to clarify that.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rework the error reporting. Unify on one message about device assignment
modes not supported by the qemu driver and move and reword the messages
for VFIO device assignment.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Historically when the code was in 'qemuHostdevPreparePCIDevicesCheckSupport'
the function returned bools. Later it was refactored and moved to
'qemuDomainPrepareHostdevPCI' the return values were not changed.
Thus the function now returned '-1', 'false', and 'true'. Callers
checked for '-1' only so the few cases forbidding legacy device
passthrough were no longer causing fatal errors.
Fixes: 3b87709c76
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Variable 'master' needs to be free because it will be reassigned in
virNetDevOpenvswitchInterfaceGetMaster().
The leaked stack:
Direct leak of 11 byte(s) in 1 object(s) allocated from:
#0 0x7f7dad8ba6df in __interceptor_malloc (/lib64/libasan.so.8+0xba6df)
#1 0x7f7dad715728 in g_malloc (/lib64/libglib-2.0.so.0+0x60728)
#2 0x7f7dad72d8b2 in g_strdup (/lib64/libglib-2.0.so.0+0x788b2)
#3 0x7f7dacb63088 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321
#4 0x7f7dacb63088 in virNetDevGetName ../src/util/virnetdev.c:823
#5 0x7f7dacb63886 in virNetDevGetMaster ../src/util/virnetdev.c:909
#6 0x7f7dacb90288 in virNetDevTapReattachBridge ../src/util/virnetdevtap.c:527
#7 0x7f7dacd5cd67 in virDomainNetNotifyActualDevice ../src/conf/domain_conf.c:30505
#8 0x7f7da3a10bc3 in qemuProcessNotifyNets ../src/qemu/qemu_process.c:3290
#9 0x7f7da3a375c6 in qemuProcessReconnect ../src/qemu/qemu_process.c:9211
#10 0x7f7dacc0cc53 in virThreadHelper ../src/util/virthread.c:256
#11 0x7f7dac2875d4 in start_thread (/lib64/libc.so.6+0x875d4)
#12 0x7f7dac3091bb in __GI___clone3 (/lib64/libc.so.6+0x1091bb)
Fixes: de938b92c9
Signed-off-by: QiangWei Zhang <zhang.qiangwei@zte.com.cn>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, virNetlinkBridgeVlanFilterSet() takes @cmd as the
second argument where either RTM_SETLINK or RTM_DELLINK is
expected. Both of these constants come from linux/rtnetlink.h and
thus are undefined when building without netlink. This design
also clashes with the whole point of virnetlink: to offload
netlink dependency onto a single file.
Therefore, drop the argument, turn
virNetlinkBridgeVlanFilterSet() into just setter, effectively,
and introduce virNetlinkBridgeVlanFilterDel() for the case when
RTM_DELLINK would be passed as @cmd.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/770
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The whole point of virnetlink.h is that it hides away the build
time dependency on netlink. It wraps netlink functions in our
functions which then have a stub implementation in case netlink
support was disabled.
Though, netlink is still Linux specific, so keep it in the
'#ifdef __linux__` block to cause a compilation error should
anybody try to use any of the wrapped functions on non-Linux.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We still use C89 style of comments. Fix C99 style of comments
used in virNetDevBridgeSetupVlans().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In virnetlink.c there are two sections: the first one when
building WITH_LIBNL support, the other that provides stubs for
functions declared in the corresponding header file when building
without netlink support. But the stub implementation for
virNetlinkBridgeVlanFilterSet() was missing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The zfs-fuse package has been dead upstream for a long time and is
now retired in Fedora rawhide.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Notable differences:
* various machine types, notably vexpress-a9, have stopped
accepting user-specified CPU models in QEMU 9.0;
* the command line for raw devices is slightly different
as libvirt now skips the 'raw' format driver blockdev.
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The borzoi machine type was dropped in QEMU 9.2.0, so let's
use a different machine type with no ACPI support and no
implicit USB controller instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
While with upstream QEMU it's impossible to have virtio-mem-ccw and not
have virtio-mem-pci, in RHEL the QEMU's build system is patched to make
that possible. But this breaks our assumption when fetching
capabilities.
Well, just do what we are already doing in this situation (e.g.
"virtio-blk-pci"/"virtio-blk-ccw" & virQEMUCapsDevicePropsVirtioBlk, or
"virtio-scsi-pci"/"virtio-net-ccw" & virQEMUCapsDevicePropsVirtioSCSI):
fetch the same set of props for both devices.
Resolves: https://issues.redhat.com/browse/RHEL-87528
Resolves: https://issues.redhat.com/browse/RHEL-87532
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This removes librbd from 32-bit arches on debian sid, which no longer
exists.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduced in v10.5.0-rc1~52, qemu and lxc hook scripts are
executed with additional argument: shutoff reason. But wording of
our docs make it looks like it's been that way forever. Make it
clear this is `recent` feature.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/766
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This patch is effectively a NOP, but it fixes a logic bug and makes the
heuristics more visible and easier to change should there be a need to
do so in the future.
We decide which CPU model is the best match for given CPU data by
comparing lists of features that need to be enabled/disabled on top of
the selected CPU model. Since the original approach of using just the
total number of features was not working well enough, commit
v8.3.0-42-g48341b025a implemented a penalty for disabled features which
would increase for each additional disabled features. Apparently the
intention was weighting disabled features as
disabled * (disabled + 3)
weightDisabled = -------------------------
2
and complete CPU model as
weight = enabled + weightDisabled
But there was a bug in the code which caused it to ignore some of the
features and counted as enabled regardless on their policy. Instead of
going through all features the code used the number of "enabled"
features (the variable was not really counting number of enabled
features though) which was initialized to the total number of features
and decremented each time a disabled features was found. Thus depending
on the number of disabled features, some features at the end of the list
were ignored. Luckily we know all the ignored features had to be
disabled because the CPU definitions were created by x86DataToCPU which
constructs a list of enabled features followed by disabled features.
So to fix the bug while providing the same results we can come up with
an equivalent formula using properly counted features in the CPU
definition.
The number of disabled features counted by the buggy code is
half = (disabled + 1) div 2
and the weight of all disabled features is
half * (half + 3)
weightDisabled = -----------------
2
When computing the total weight, we can't no longer use number of
enabled features because the original code counted some of the disabled
features as enabled. So to match the old behavior, we count the total
weight as
weight = features - half + weightDisabled
The weight of enabled features now differs from the value computed by
the old code, but we don't need to worry about it as it's not really
used anywhere except for logging.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/759
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Refactor weight calculation to a separate virCPUx86WeightFeatures
function to avoid code duplication. The algorithm is not changed during
the refactoring, it will be fixed later.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Update the replies and xml files for QEMU 10.0.0 on s390x based on
the released QEMU tag v10.0.0 with the commit Id
7c949c53e936aa3a658d84ab53bae5cadaa5d59c.
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>
This is purely a devel-time problem in the test suite.
'qemuxmlactivetest' invokes the whole test worker twice, once for
inactive output and second time for active.
Now 'testQemuInfoInitArgs' returns a failure if the XML is invalid and
the test is skipped. On another invocation though it returns 0 if
'testQemuInfoSetArgs' was not invoked meanwhile and thus makes it seem
it succeeded which leads to a crash in the code assuming that some
pointers are valid.
Use same interlocking as 'qemuxmlconftest' to skip the second invocation
on failure of the first one.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The files were forgotten after the previous bump to use qemu-5.2 as
minimum. The data for qemu-5.2, qemu-6.0, and qemu-6.1 was already
removed when bumping to qemu-6.2.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The common x86_64 test output was usually built without GTK as I've had
that in my build script for a long time. Enable it now as GTK UI is
enabled by many distros and upcoming patches plan to add support to
libvirt as well.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The script is renamed to mockable-attribute.py and adjusted to
check for the new attribute.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Per change in coding style done in previous commit,
ATTRIBUTE_MOCKABLE should be used instead of G_NO_INLINE for
functions that are mocked in our test suite. Do the change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently, if we want to mock a function the noinline attribute
is appended after the function (via G_NO_INLINE macro). This used
to work for non pure functions. But there are some trivial
functions (for instance virQEMUCapsProbeHVF()) that are pure,
i.e. have no side effect, and while their call from other parts
of the code is not optimized out, their call from within the same
compilation unit (qemu_capabilities.c) is optimized out.
This is because inlining and semantic interposition are two
different things. Even GCC's documentation for noinline attribute
[1] states that clearly:
This function attribute prevents a function from being
considered for inlining. It also disables some other
interprocedural optimizations; it’s preferable to use the more
comprehensive noipa attribute instead if that is your goal.
Even if a function is declared with the noinline attribute,
there are optimizations other than inlining that can cause
calls to be optimized away if it does not have side effects,
although the function call is live.
Unfortunately, despite attempts [2] Clang still does not support
the attribute and thus we have to rely on noinline +
-fsemantic-interposition combo.
1: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noinline-function-attribute
2: https://reviews.llvm.org/D101011
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Allow virCommand to find them in $PATH, which will always include 'sbin'
since the openvz driver only operates in system mode.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Change the meson rules to always enable the LVM driver if on a
Linux host, unless the meson options say not to.
The virCommand APIs will return suitable runtime errors if the
tools are not installed.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is no reference to AUGPARSE, BLACK, FLAKE8, PDWTAGS or PYTEST conf
variables anywhere, only the ${name}_prog meson variables are used.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow virCommand to find 'tc' in $PATH. This command is only used
when running privileged in which case both 'bin' and 'sbin' dirs will
be in $PATH, so virFindFileInPath will do the right thing to find it.
Since there are no longer any optional programs, only optional test
programs, the meson variables can be renamed and simplified at this
point.
The "TC" constant is defined in the header to match the pattern used
for the other firewall tool names.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow virCommand to find 'ovs-vsctl' in $PATH. This command is only used
when running privileged in which case both 'bin' and 'sbin' dirs will
be in $PATH, so virFindFileInPath will do the right thing to find it.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow virCommand to find 'modprobe' & 'rmmod' in $PATH. These commands
are only used when running privileged in which case both 'bin' and
'sbin' dirs will be in $PATH, so virFindFileInPath will do the right
thing to find them.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow virCommand to find 'mm-ctl' in $PATH. This command is only used
when running privileged in which case both 'bin' and 'sbin' dirs will
be in $PATH, so virFindFileInPath will do the right thing to find it.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow virCommand to find 'mdevctl' in $PATH. This command is only used
when running privileged in which case both 'bin' and 'sbin' dirs will
be in $PATH, so virFindFileInPath will do the right thing to find it.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Gating the iscsi driver backend on a isciadm probe is likely to do
more harm than good as it needlessly disables the code if the dev
forgot to install iscsiadm at build time. As a Linux only command
it is simpler to gate the feature based on the platform choice and
allow missing binaries to be diagnose at runtime.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There are no references to an "IP" conf variable nor a meson
'ip_prog' variable so the check serves no purpose.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow virCommand to find 'dmidecode' in $PATH. This command is only
usable when running privileged since it relies on reading from a
privileged kernel file. Thus we can assume both 'bin' and 'sbin' dirs
will be in $PATH and virFindFileInPath will do the right thing to
find it when called by virCommand.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is no reference to PERL, PYTHON3, XMLLINT or XSLTPROC conf
variables anywhere, only the ${name}_prog meson variables are
used.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently $(PERL) is expanding to nothing, but the spacing-check.pl test
luckily still works via the shebang.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Nothing in the tree references RST2MAN or RST2HTML5 variables, only
rst2man_prog & rst2html5_prog, so the former can be removed.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Change the source to assume use of 'ifconfig' on FreeBSD builds,
allowing virCommand to report missing commands at runtime.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Change the meson rules to always enable bhyve if on a FreeBSD host,
unless the meson options say not to.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Change the meson rules to always enable numad if on a Linux host, unless
the meson options say not to.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is redundant since the tests will strip any path component from the
binary name before comparison.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This was always undesirable but now causes problems on Fedora 42
where at build time we detect a /sbin path but at runtime this
will only exist on upgraded machines, not fresh installs.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The mock-noinline.py script is fed list of files through its
stdin, each file on its own line. Unfortunately, the way the
script is written does nothing as the trailing newline character
prevents any .endswith() match. Strip each line of white spaces.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are two functions that are mocked, but are missing required
G_NO_INLINE attribute: virFirewallDIsRegistered() and
virHostCPUGetPhysAddrSize(). Add it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The updated doc refers to both the old and new error message, as users
with old deployed versions will still be pointed to the current online
docs URL.
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When no URI is set we try to guess what daemon to connect to by looking
for any listening sockets. If there are no listening sockets, however,
we don't even know what daemon the user expected to connect to. The
error message in this case is not especially clear
This tweaks the error message to try to make the problem easier to
understand.
Resolves: https://issues.redhat.com/browse/RHEL-87177
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Update the data after the release.
Notable changes:
- the 7.0 machine types became deprecated
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If a variable is not modified in a scope there is no need for the use of
global in such scope. Without this patch build fails with:
F824 `global ...` is unused: name is never assigned in scope
It is a bit difficult to find more information on that message and error
code, I found it here:
https://docs.astral.sh/ruff/rules/global-variable-not-assigned/
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Commit 5de27c32a1 wanted to fix a possible double free, but by mistake
did not pass a reference to the variable. This made virtnwfilterd
coredump in our daily CI build.
Fixes: 5de27c32a1
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This function return value is invariant since e59b8f9, so change
its type and remove all dependent checks.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Signed-off-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
As commit 50981052a5 mentioned, the currentAddress in live domain
XML, requires virtio model as well.
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As virDomainNet* functions were converted to use const virDomainDef
pointers, update bhyveBuildNetArgStr() as well, like it was before it was
changed in e1e40b5035.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some virDomainNet* functions use virDomainDef pointers even though they
don't modify the domain config, so switch to const pointers there.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
path is allocated by asprintf() and must be freed later if realloc() fails.
Restructure the code to allocate path only after realloc() succeeds,
avoiding the need for an extra free().
Found by Linux Verification Center (linuxtesting.org) with Svace.
Reported-by: Dmitry Fedin <d.fedin@fobos-nt.ru>
Signed-off-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virNWFilterInstReset() may be called multiple times, leading to a double g_free()
Replace plain g_free() with g_clear_pointer() to prevent this
Found by Linux Verification Center (linuxtesting.org) with Svace.
Reported-by: Dmitry Fedin <d.fedin@fobos-nt.ru>
Signed-off-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virXPathString() can return NULL so we need to use STRNEQ_NULLABLE here
Found by Linux Verification Center (linuxtesting.org) with Svace.
Reported-by: Dmitry Fedin <d.fedin@fobos-nt.ru>
Signed-off-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
- Document the virtio random number generator device support
- While here, remove mention of the specific FreeBSD version such as
10-STABLE, and just refer to the latest supported release.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Document the virtio random number generator device support
and <interface type='network'> support.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The aim of the progname member of the _vshControl struct is to
point to argv[0] which is then used in vshOutputLogFile() to
create a prefix for a log message. But the member is never
modified (nor it should be) and thus can be a const char *.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Whether virsh/virt-admin is running in interactive or
non-interactive mode, vshControl::cmd contains the batch of last
executed commands as a linked list. Just look into
vshCommandParse(). Free the linked list in vshDeinit() to avoid
memleak.
3,312 bytes in 3 blocks are still reachable in loss record 572 of 577
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x506AB29: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8200.5)
by 0x1B74B8: vshCmdNew (vsh.c:1466)
by 0x1B7A80: vshCommandParse (vsh.c:1615)
by 0x1B8458: vshCommandStringParse (vsh.c:1874)
by 0x1419C1: virshParseArgv (virsh.c:773)
by 0x141D11: main (virsh.c:879)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'qemuBuildThrottleFiltersAttachPrepareBlockdev' can fail when
constructing JSON props, but otherwise always retruns a pointer even if
there's nothing to do.
The code in 'qemuDomainAttachDiskGeneric' didn't handle this properly as
it considered NULL as "nothing to do". Return the failure instead and
check if tere's something to do by looking at 'nfilterdata'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'qemuBlockThrottleFiltersDetach' crashes if @data is NULL. That can
happen in 'qemuDomainAttachDiskGeneric' as it's used as a rollback path
in cases when we didn't yet initialize the filter struct.
Fix it by tolerating NULL @data.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/765
Fixes: 9a6560f066
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When "original passt" support was added, we decided that we always
wanted to reconnect (i.e. restart the passt process) if it was somehow
terminated. Generic vhost-user, on the other hand, only turns on
reconnect if specified by the user in the config. But there is no
reason to require the user to specify this if the other end of the
vhost-user socket is a passt process - we know what has happened and
what we want to do; no reason to do the *wrong* thing by default, and
force the user to make an arbitrary decision about what to add to the
config in order to make it do the *right* thing; instead we just
hardcode it to always do the right thing.
(NB: when the backend is passt, <interface type='vhostuser'> has
always ignored the reconnect setting in <source> when parsing and
formatting, just as it has always ignored the socket path (since that
also is not user configurable for the passt backend)
Resolves: https://issues.redhat.com/browse/RHEL-80169
Signed-off-by: Laine Stump <laine@redhat.com>
Tested-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Rather than duplicating these two lines of chr device object setup for
hotplug and domain start, put them in a helper function that's called
from both places. That way when we need to setup *more* stuff specific
to passt+vhostuser, we can just add it in that one place.
Signed-off-by: Laine Stump <laine@redhat.com>
Tested-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This response to this event is identical to NETDEV_STREAM_DISCONNECTED
(start a new passt process to replace the one that just disappeared -
see commitf62ce81b8a5), except that the new passt process will have
"--vhost-user" appended to the commandline. Fortunately that
difference is already handled based on the virDomainNetDef contents,
so we can, in fact, respond to the new event in exactly the same
manner.
Signed-off-by: Laine Stump <laine@redhat.com>
Tested-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We will be adding a new event whose response will be *exactly* the
same as the response to NETDEV_STREAM_DISCONNECTED. Rather than doing
a copy-paste of the complete function that does the processing, turn
that function into something more generic that takes the name of the
event as an arg (the event name is only used in log messages).
Signed-off-by: Laine Stump <laine@redhat.com>
Tested-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
By definition QEMU will never send a NETDEV_STREAM_DISCONNECTED event
if it doesn't support the reconnect option for a stream netdev. And
even if, by some comedy of errors, it did send
NETDEV_STREAM_DISCONNECTED in that case, our response to the event
doesn't request anything at all of QEMU (much less something that
would fail if QEMU didn't understand NETDEV_STREAM_DISCONNECTED) - it
just starts a new passt process to replace the one that has been
terminated, so we don't need to check the QEMU capabilities for
QEMU_CAPS_NETDEV_STREAM_RECONNECT.
Signed-off-by: Laine Stump <laine@redhat.com>
Tested-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If the copy job fails to start up when calling the 'blockdev-mirror'
command the code would call qemuDomainStorageSourceChainAccessRevoke()
twice; once right after the monitor call and the second time in the
'endjob' section.
Remove the one directly after the monitor call and let the common
cleanup handle it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While exploring an idea that modified the setup of the mirror I've
noticed that the code setting up the 'discard' field in the block copy
job happens after setup of the storage source, while normally e.g. in
qemuDomainPrepareStorageSource() it happens before.
Reorder it despite not having an effect currently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add support for interface type 'network'. While bridge remains the only
supported options for networks in bhyve, supporting interface type
'network' allows easier configuration and makes domain XMLs more
compatible with the other drivers.
While here, update the error message for the unsupported interface type
to print the requested network type string instead of an integer to make
it more user-friendly.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a bunch of device def validation to catch unsupported RNG device
configurations early.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve supports the Virtio RNG interface. It's always using the
/dev/random device and doesn't have any configuration options.
Thus, in XML it's represented as:
<rng model='virtio'>
<backend model='random'/>
</rng>
So extend the bhyve driver to support that and add a set of tests for
this feature.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When migrating a domain with TPM state on a shared disk, we need to skip
TPM cleanup on both ends. So far the code only handled successful
migration and skipped the cleanup on the source host. But if the
migration failed for some reason, the cleanup would be incorrectly
called on the destination host removing the TPM files even though the
domain was still running on the source host.
https://issues.redhat.com/browse/RHEL-82411
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The parameter is used to skip TPM state cleanup on outgoing migration
with shared storage. But we also need to skip the cleanup after a failed
incoming migration. Let's call the parameter "migration" to reflect its
usage on both sides of migration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When the network driver initializes itself, it tries to subscribe
to signals from Firewalld sent over system D-Bus. Well, the code
is written in best effort mode, i.e. lack of D-Bus is not
considered an error. Problem is, virGDBusGetSystemBus() which is
used to obtain system D-Bus prints out an error in case of
lacking system D-Bus. This pollutes the logs (which may mislead
users) and goes against the best-effort nature of aforementioned
code. Check for the system D-Bus presence via
virGDBusHasSystemBus() first.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
At the beginning of virInhibitorAcquire() the system D-Bus
connection is obtained by calling virGDBusGetSystemBus(). If
there's no D-Bus available then an debug message is printed out
and function returns early. Problem is, in case of no D-Bus an
error message was reported by virGDBusGetSystemBus() and thus
logs were polluted which may mislead users.
Just check whether D-Bus is available first (by calling
virGDBusHasSystemBus()). If it is then virGDBusGetSystemBus()
should return a valid connection. Nevertheless, respect previous
logic and don't propagate error to the caller, just return 0.
Resolves: https://issues.redhat.com/browse/RHEL-79088
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add the news entry stating that it's safe to ignore the error.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
qemuRdpAvailable() is called from the capability filing code, thus:
- it must not report spurious errors
- it should not call any extra processes
We can solve the above by just checking existance of 'qemu-rdp' in the
path as:
- at the time of adding of qemuRdpAvailable() there was only one 'qemu-rdp' release
- it supported all the features
- the check can't change as we'd drop the capability
Add comments and gut the check to only check existance of the file.
Fixes: f5e5a9bec9
Closes: https://gitlab.com/libvirt/libvirt/-/issues/763
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
When connecting to "esx://" URI there's code which prints a warning that
the path is not "empty". The check validates that "uri->path" is "/".
In case when the user uses URI such as:
esx://hostname
the warning is printed as well. Since there is no effective difference
betweeen the two allow empty strings as well.
Resolves: https://issues.redhat.com/browse/RHEL-86459
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Adapt the disclarimer about the data not being accurate in many cases
from the API docs to the virsh command using the aforementioned API.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virNodeGetInfo due to the rigid desing of the filled struct can't
faithfully represent all topologies. Improve the description when that
happens and outline the fallback topology.
The function docs already state that users ought to use
virConnectGetCapabilities() instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'virNodeInfo' field for CPU frequency is named 'mhz'. The docs were
mentioning 'mHZ', which is neither the field name nor proper spelling of
the unit.
Reword the paragraph to mention "CPU frequency" instead and explicitly
name the field in virNodeInfo struct.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As the cleanup section is empty; the code can now return directly on
errors.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use 'g_autfree' for the two temporary strings.
'sysfs_cpudir' was used in two places, one of which is in a loop. Add
another helper variable for it and declare the other one in the loop.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The capability wasn't used since it's inception. It now refers to a
deprecated QMP command. Drop it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'block-export-add' command was added in qemu-5.2 so we now use it
unconditionally.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'block-export-add' QMP command which replaces 'nbd-server-add' was
introduced in qemu-5.2. We can thus drop the old code now.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When the new storage was created using virsh with --validate option
following errors occurred:
# virsh vol-create default --file vol-def.xml --validate
error: Failed to create vol from vol-def.xml
error: unsupported flags (0x4) in function virStorageVolDefParseXML
and after virStorageVolDefParse fix:
# virsh vol-create default --file vol-def.xml --validate
error: Failed to create vol from vol-def.xml
error: unsupported flags (0x4) in function storageBackendCreateQemuImg
Clear the VIR_VOL_XML_PARSE_VALIDATE flag before
virStorageVolDefParseXML() and the VIR_STORAGE_VOL_CREATE_VALIDATE before
backend->buildVol() (traces down to storageBackendCreateQemuImg) calls,
as the XML schema validation is already complete within previous steps
and there is no validation later.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Finding the correct link to a XML description or API reference section
in a big blob of links concatenated in a paragraph is unpleasand and
especially for 'capabilities' and 'domain capabilities' following each
other.
Turn the API and XML reference sections into a list in RST and add CSS
to fromat it a bit more compact.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Swap the order of links to XML schema docs and to the other language
docs. The XML schema is usually accessed more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The purpose of this test is to enforce loading and parsing of ARM CPU
map so that possible issues are found earlier.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After previous cleanups, all functions have their stack smaller
than 2048 bytes and thus the workaround is no longer needed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
There's too much happening inside of vboxSnapshotRedefine(). Not
only it makes the function hard to read, but it also increases
stack size of the function. Move one part into a separate
function: vboxSnapshotCreateFakeDiffStorage()
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
There's too much happening inside of vboxSnapshotRedefine(). Not
only it makes the function hard to read, but it also increases
stack size of the function. Move one part into a separate
function: vboxSnapshotAddRWDisks()
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
There's too much happening inside of vboxSnapshotRedefine(). Not
only it makes the function hard to read, but it also increases
stack size of the function. Move one part into a separate
function: vboxSnapshotAddDisksToMediaRegistry()
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
There's too much happening inside of vboxSnapshotRedefine(). Not
only it makes the function hard to read, but it also increases
stack size of the function. Move one part into a separate
function: vboxSnapshotReplaceRWDisks()
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The @transport variable is already pass into the function with
proper type. There's no need to typecast it to its very same type
inside the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
When opening a connection, the client does some RPC talk
(most notably REMOTE_PROC_CONNECT_OPEN, and in some cases
REMOTE_PROC_CONNECT_GET_URI even).
Now, calling RPC means that local variables must be created.
Having them in doRemoteOpen() increases its stack size which goes
against our effort in bringing the size down (see one of previous
commits).
Move that part of the code into a separate function.
This brings the stack size of doRemoteOpen() even further: from
1320 bytes to 1272.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
There's a problem with glib: what we might consider functions are
in fact macros and to make things worse - they do declare local
variables. For instance here's the declaration of
g_clear_pointer() macro:
#define g_clear_pointer(pp, destroy) \
G_STMT_START \
{ \
G_STATIC_ASSERT (sizeof *(pp) == sizeof (gpointer)); \
glib_typeof ((pp)) _pp = (pp); \
glib_typeof (*(pp)) _ptr = *_pp; \
*_pp = NULL; \
if (_ptr) \
(destroy) (_ptr); \
} \
G_STMT_END \
Now, as of v6.2.0-rc1~267 our VIR_FREE() macro is in fact a
redeclaration of g_clear_pointer(). Thus, calling VIR_FREE()
increases stack size!
Ideally, this wouldn't be a problem, because those variables
(_pp, _ptr) live in their own block. And clever compiler can just
reuse space created for one block.
But then there's clang where we are hitting this exact problem in
functions like doRemoteOpen() where either g_clear_pointer() is
called directly, or there are macros like EXTRACT_URI_ARG_STR()
which hide the call away.
That's why despite our previous efforts decreasing stack size we
still needed v9.8.0-rc1~208.
Well, moving URI argument extraction (those calls to
EXTRACT_URI_ARG_* macros) into a separate function helps us
decrease stack size from 2296 bytes to 1320.
Even after this there are still more possibilities for
improvements, but those will be addressed in future commits.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
In a few places, when a size_t typed argument is passed to a
printf-like function the corresponding specifier is %ld instead
of %zu. Fix those places.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The domain object already has a member that allows storing
hypervisor's PID (vm->pid). There's no need to duplicate it in
_virCHMonitor struct. Switch CH code to use the former.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two instances where vm->privateData is typecasted only
so that it can be dereferenced further. Well, that's exactly what
CH_DOMAIN_PRIVATE() macro is for. Use that instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Adds support for configuring <hyperv/> flags for domains
running under Xen.
The following flags, making use of QEMU's existing flags, are now
configurable for Xen: vapic, synic, stimer, frequencies, tlbflush and
ipi.
Tests have been added validating translation to libxl's viridian flags
Updated docs section on <hyperv/> flags to note support and to specify
which flags work with Xen.
Signed-off-by: Will <tcosprojects@gmail.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
When using the default SLIRP backend for <interface type='user'>, the
<ip address='blah' prefix='blur'/> setting doesn't behave as might be
expected (i.e. it doesn't set the guest interface IP/prefix to exactly
the provided values). This *should* have created questions when users
originally encountered it, but instead it has become more apparent as
people are contemplating switching from using the SLIRP backend to
using passt instead (with passt, the <ip> settings do behave "as
expected").
In order to make this difference in behavior less mysterious, Yalan
Zhang kindly took the time to test and document the effect of various
representative <ip> settings on guest interface config when SLIRP is
used (see https://issues.redhat.com/browse/RHEL-46601); this patch
adds that same table to libvirt's documentation.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the domain shutdown was executed from virsh, only the VM
process (a child of the CH monitor) was terminated. Since we assume
only one VM per monitor, the monitor process should also be
terminated.
Modified the VM shutdown event handler to match the VMM shutdown
behavior, ensuring the VM monitor stops along with the VM. Also
updated the virCHEventStopProcess job type, as it only destroys the
domain rather than modifying anything.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the domain was rebooted, some of its properties were changed but
not updated in the transient domain definition. This led to the
inability to connect to the serial console as its path had changed
during the reboot but was not updated in the domain definition.
Added VIR_CH_EVENT_VM_REBOOTED event handling to update the
information in transient domain definition after domain's reboot is
completed to maintain it in consistent state.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the new CH monitor was started, it ran as a non-daemonized
process and was a child of the CH driver process. This led to a
situation where if the CH driver died, the monitor process were
killed too, terminating the running VM under the monitor. This
led to termination of all VM started under the libvirt.
Make new monitor running daemonized to avoid VMs shutdown when
driver dies. Also added a pidfile its preparetion to be able
to aquire daemon's PID.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The code now always assumes support for the QMP internal snapshot
commands so the capability is no longer needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we've replaced the final two HMP commands used by libvirt we
can fully drop the 'text' monitor support.
The only thing we keep is the HMP passtrhough with
'virsh qemu-monitor-command'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As all supported qemu versions now support the QMP internal snapshot
commands (QEMU_CAPS_SNAPSHOT_INTERNAL_QMP is always present) we can
remove the code for loading snapshots during startup via '-loadvm'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'snapshot-save' QMP command was introduced in 'qemu-6.0' and libvirt
now requires at least 'qemu-6.2'. Thus we can assume that the QMP
command can be used always.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'ret' variable is set to 0 before a call which can theoretically
fail. Not in practice really as the failure scenarion includes only
object initialization.
Since the code already has another variable for checking monitor returns
use that one properly so that the code makes sense.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As 'virCPUDefCopy' can't fail any more (without aborting) remove the
last two return value checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The macro checking monitor object state also logs information such as
the monitor object pointer and the number of the monitor FD.
Name the field 'monfd' instead of 'fd' as it's confusing when debugging
FD pasing via monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In deployments where libvirt is containerized together with the VM it
may be hard for the management application to access listening sockets
inside the container from the outside.
This patch implements "transport='fd'" for the NBD server definition for
backups which allows to use the existing "virDomainFDAssociate()" to
pass FD to a pre-opened server socket to qemu instead of trying to
create it by qemu.
Add schema, enable the parser, add formatter and implement the actual
passing for the qemu backup code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Spellchecked-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will extend the FD passing infrastructure to the backup
job so that users can pass an opened socket instead of qemu opening it
themself to bypass difficulities caused by containerizing libvirt.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prepare the parser code and anything using 'virStorageNetHostTransport'
to support passing a FD instead of opening the connection by qemu
itself.
For now this just prepares the parser and data structures, but the code
is dormant.
Only code paths which will actually support FD passing will then enable
it in the future.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Spellchecked-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use a 'switch' statement instead of a bunch of if statements to do
validation and selection what to parse.
Remove the pre-clearing of the struct as we always allocate cleared
memory for it and we can reorder assignments to avoid the need for
cleanup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since the refactor to use proper enum type for the network transport the
'transport' variable is no longer filled. Remove it and fix the error
message which references it without using NULLSTR.
Fixes: 452695926d
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As the 'dataStore' is internally represented as a virStorageSource
object it has provisions for nesting which is not supported.
When I've reviewed and modified the commit adding data file parsing
support I've added code that was supposed to reject any 'backingStore'
and 'dataStore' structures nested in a source of a 'dataStore'.
Unfortunately the check was broken as one of the terms checked the
presence of parent's 'backingStore' instead of the nesting.
Fix it and add tests.
Fixes: b3171cf8da
Resolves: https://issues.redhat.com/browse/RHEL-85320
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In esxConnectListAllDomains if the lookup of the VM name and UUID fails
for a single VM (possible e.g. with broken storage) the whole API would
return failure even when there are working VMs.
Rework the lookup so that if a subset fails we ignore the failure on
those. We report an error only if lookup of all of the objects failed.
Failure is reported from the last one.
Resolves: https://issues.redhat.com/browse/RHEL-80606
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we mandate version 3, any remaining conditional checks
in meson/source code can be removed.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit 19eb8abc9a.
There is no longer any need to dynamically generate version specific
rules. This revert can be reverted, if the need ever arises again
in the future.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit 63a312fa2d.
There is no longer any need to dynamically generate version specific
rules. This revert can be reverted, if the need ever arises again
in the future.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
By assuming version 3, we can drop all the conditional version
substitutions from the profiles.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We can now assume at least version three:
* Debian 12: 3.0.8
* openSUSE Leap 15.5: 3.0.4
* openSUSE Leap 15.6: 3.1.7
* Ubuntu 22.04: 3.0.4
* Ubuntu 24.04: 4.0.0
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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>
This comment is wrong as later qemuMigrationSrcRun() is called which
checks if TLS should be used and activated. QEMU has built-in support
for TLS, which this refers to.
The comment originates from a time when tunneled support was the only
way to get encryption.
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
When invoking virDomainSaveParams with a relative path, the image is
saved to the daemon's CWD. Similarly, when providing virDomainRestoreParams
with a relative path, it attempts to restore from the daemon's CWD. In most
configurations, the daemon's CWD is set to '/'. Ensure a relative path is
converted to absolute before invoking the driver domain{Save,Restore}Params
functions.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit 28a0621528 added support to restore
sparse images but changed the boolean that controls if we open the file
as read-only or read-write. Editing XML in the save image resulted in
following error message:
failed to write header to domain save file '/data/images/fedora40.save': Bad file descriptor
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
So far, we only process NIC_RX_FILTER_CHANGED event when the
corresponding device has 'trustGuestRxFilters' enabled. And the
event is emitted only for virtio model. IOW, this is fairly
limited situation and other scenarios don't emit any event (e.g.
change of MAC address on a PCI passthrough device).
Resolves: https://issues.redhat.com/browse/RHEL-7035
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The aim off this event is to notify management application that
guest changed MAC address on one of its vNICs so the app can
update its internal records, e.g. for finding match between
guest/host view of vNICs.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
If a guest changes MAC address on its vNIC, then QEMU emits
NIC_RX_FILTER_CHANGED event (the event is emitted in other cases
too, but that's not important right now). Now, domain XML allows
users to chose whether to trust these events or not:
<interface trustGuestRxFilters='yes|no'/>
For the 'no' case no action is performed and the event is
ignored. But for the 'yes' case, some host side features of
corresponding vNIC (well tap/macvtap device) are tweaked to
reflect changed MAC address. But what is missing is reflecting
this new MAC address in domain XML.
Basically, what happens is: the host sees traffic with new MAC
address, all tools inside the guest see the new MAC address
(including 'virsh domifaddr --source agent') which makes it
harder to match device in the guest with the one in the domain
XML.
Therefore, report this new MAC address as another attribute of
the <mac/> element:
<mac address="52:54:00:a4:6f:91" currentAddress="00:11:22:33:44:55"/>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In the two cases when we know that the command returned failure switch
to the new error code so that management applications can
programatically detect failure of the guest agent command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a special error code for when the guest agent returned a failure
message.
Allow management applications to deterministically detect failure of the
guest agent command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In addition to the error constant appearing add docs hinting that this
new error code can be produced on timeouts.
The most relevant place is to do it when setting the timeout.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When the agent disappears after geting a proper command we ought to
report the same error code as if we timed out as it's uncertain whether
the guest agent did anything.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As the guest agent code uses timeouts it is possible that we stop
waiting before the guest agent replies. If this happens while syncing
everything is okay because we didn't send any state-changing command.
In case when the timeout happens after a real command was transmitted
it's unknown if the guest-agent processed it or not.
Use the new special error code VIR_ERR_AGENT_COMMAND_TIMEOUT for cases
when we sent non-sync commands, so that the management applications or
users have possibility to react to this situation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a new special error code for guest agent commands.
The error code will be specifically reported only when an actual command
(not a sync) was issued to the guest agent and the timeout time was
reached.
This will allow users and management applications to differentiate
between the cases when the sync timed out and thus there's no risk in
the agent actually having executed the command and when the actual
command was sent.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a 'New features' entry for mapped-ram itself, and another
for the parallel save/restore feature built on top.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commits c2518f7bc7 and 28a0621528 introduced build failures on 32-bit
platforms by using incorrect format specifiers with g_strdup_printf.
In one case, an 'unsigned long' format specifier is used with a
'long long int' variable. Fix by changing the format specifier to
'uintmax_t', and casting the variable likewise.
In a second case, an 'unsigned long' format specifier is used with a
'size_t' variable, which is 'unsigned int' on 32-bit systems. Fix by
changing the format specifier to use the 'z' modifier.
Fixes: c2518f7bc7
Fixes: 28a0621528
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Option --parallel-channels would require changing configuration file to
be used so introduce this option as well to make it convenient for
users.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
We should use the newest API only when user sets parallel-channels.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
We should use the newest API only when user sets parallel-channels.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
There is no need to use extra flag in addition to the new
"parallel.channels" param.
Using the flag without param would result in using uninitialized
variable. Fixing it would result in error that parallel channels cannot
be less then 1 or setting 1 as default.
Using the param without the flag is ignored.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
There is no need to have --parallel and --parallel-channels especially
when --parallel on its own is the same as not used at all. In both cases
libvirt will default to single channel.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
There is no need to have --parallel and --parallel-channels especially
when --parallel on its own is the same as not used at all. In both cases
libvirt will default to single channel.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
In commit dbfb96d18c libvirt started connecting to the daemon to set
RDP credentials, but our configuration file did not allow connections
from the root user, so the connection failed and the VM failed to start.
In order to avoid such issue allow root to connect if the daemon is
running privileged.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add support for parallel save and restore by mapping libvirt's
"parallel-channels" parameter to QEMU's "multifd-channels"
migration parameter.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add a new VIR_DOMAIN_SAVE_PARALLEL flag to the save and restore APIs,
which can be used to specify the use of multiple, parallel channels
for saving and restoring a domain. The number of parallel channels
can be set using the VIR_DOMAIN_SAVE_PARAM_PARALLEL_CHANNELS
typed parameter.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When using the mapped-ram migration capability, direct IO is
enabled by setting the "direct-io" migration parameter to
"true" and passing QEMU an additional fd with O_DIRECT set.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When using the mapped-ram migration capability, direct IO is
enabled by setting the "direct-io" migration parameter to
"true" and passing QEMU an additional fd with O_DIRECT set.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add support for the mapped-ram migration capability on restore.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Similar to qemuMigrationSrcRun, apply migration parameters in
qemuMigrationDstRun. This allows callers to create customized
migration parameters, but delegates their application to the
function performing the migration.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
qemuProcessStartWithMemoryState() is the only caller of qemuProcessStart()
that uses the qemuProcessIncomingDef struct. Move creation of the struct
to qemuProcessStartWithMemoryState().
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce support for QEMU's new mapped-ram stream format [1].
mapped-ram can be enabled by setting the 'save_image_format'
setting in qemu.conf to 'sparse'.
To use mapped-ram with QEMU:
- The 'mapped-ram' migration capability must be set to true
- The 'multifd' migration capability must be set to true and
the 'multifd-channels' migration parameter must set to 1
- QEMU must be provided an fdset containing the migration fd
- The 'migrate' qmp command is invoked with a URI referencing the
fdset and an offset where to start reading or writing the data
stream, e.g.
{"execute":"migrate",
"arguments":{"detach":true,"resume":false,
"uri":"file:/dev/fdset/0,offset=0x11921"}}
The mapped-ram stream, in conjunction with direct IO and multifd
support provided by subsequent patches, can significantly improve
the time required to save VM memory state. The following tables
compare mapped-ram with the existing, sequential save stream. In
all cases, the save and restore operations are to/from a block
device comprised of two NVMe disks in RAID0 configuration with
xfs (~8600MiB/s). The values in the 'save time' and 'restore time'
columns were scraped from the 'real' time reported by time(1). The
'Size' and 'Blocks' columns were provided by the corresponding
outputs of stat(1).
VM: 32G RAM, 1 vcpu, idle (shortly after boot)
| save | restore |
| time | time | Size | Blocks
-----------------------+---------+---------+--------------+--------
legacy | 6.193s | 4.399s | 985744812 | 1925288
-----------------------+---------+---------+--------------+--------
mapped-ram | 5.109s | 1.176s | 34368554354 | 1774472
-----------------------+---------+---------+--------------+--------
legacy + direct IO | 5.725s | 4.512s | 985765251 | 1925328
-----------------------+---------+---------+--------------+--------
mapped-ram + direct IO | 4.627s | 1.490s | 34368554354 | 1774304
-----------------------+---------+---------+--------------+--------
mapped-ram + direct IO | | | |
+ multifd-channels=8 | 4.421s | 0.845s | 34368554318 | 1774312
-------------------------------------------------------------------
VM: 32G RAM, 30G dirty, 1 vcpu in tight loop dirtying memory
| save | restore |
| time | time | Size | Blocks
-----------------------+---------+---------+--------------+---------
legacy | 25.800s | 14.332s | 33154309983 | 64754512
-----------------------+---------+---------+--------------+---------
mapped-ram | 18.742s | 15.027s | 34368559228 | 64617160
-----------------------+---------+---------+--------------+---------
legacy + direct IO | 13.115s | 18.050s | 33154310496 | 64754520
-----------------------+---------+---------+--------------+---------
mapped-ram + direct IO | 13.623s | 15.959s | 34368557392 | 64662040
-----------------------+-------- +---------+--------------+---------
mapped-ram + direct IO | | | |
+ multifd-channels=8 | 6.994s | 6.470s | 34368554980 | 64665776
--------------------------------------------------------------------
As can be seen from the tables, one caveat of mapped-ram is the logical
file size of a saved image is basically equivalent to the VM memory size.
Note however that mapped-ram typically uses fewer blocks on disk, hence
the name 'sparse' for 'save_image_format'.
Also note the mapped-ram stream is incompatible with the existing stream
format, hence mapped-ram cannot be used to restore an image saved with
the existing format and vice versa.
[1] https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/mapped-ram.rst?ref_type=heads
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Move the code in qemuSaveImageCreate that opens, labels, and wraps the
save image fd to a helper function, providing more flexibility for
upcoming mapped-ram support.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce qemuMigrationParamsForSave() to create a
qemuMigrationParams object initialized with appropriate migration
capabilities and parameters for a save operation.
Note that mapped-ram capability also requires the multifd capability.
For now, the number of multifd channels is set to 1. Future work
to support parallel save/restore can set the number of channels to
a user-specified value.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add the mapped-ram migration capability introduced in QEMU 9.0.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add new function qemuMigrationParamsCapEnabled() to check if a
capability is set in the caller-provided migration parameters.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add new function qemuFDPassNewFromMonitor to get an fdset previously
passed to qemu, based on the 'prefix' provided when the qemuFDPass
object was initially created.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Update "attach_disk" to support new option: throttle-groups to
form filter chain in QEMU for specific disk
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Fixed alignment of child elements in the XML
* Fixed placement of the throttlegroups element
* Removed completer wrapper
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Implement new throttle cmds
* Add new virsh cmds: domthrottlegroupset, domthrottlegrouplist,
domthrottlegroupinfo, domthrottlegroupdel
* Add doc for new cmds at docs/manpages/virsh.rst
* Add cmd helper "virshDomainThrottleGroupCompleter", which is used by
domthrottlegroupset, domthrottlegroupinfo, domthrottlegroupdel
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Update of code documentation comments.
* Reimplement Get throttle group from XML.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>a
* Fixed memleaks
* Rewrote getter to avoid extra copies
* Simplified name extractor
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Define macro for iotune options, this macro is used by opts_blkdeviotune and
later throttle group opts
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
* Add tests for throttlefilter nodename parse and format for statusxml
(disk/privateData/nodenames/nodename with type='throttle-filter')
* Add iotune limited disk tests to make sure iotune refactory works
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Isolate status xml test
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
* Add tests for throttlegroup domain xml processing, including
groups referenced and not referenced by filters
* Add tests for throttlefilter domain xml processing, including
throttle group referenced by different disks
* Add negative test case to report error when iotune is configured
together with throttle filters
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Isolate domain xml test
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Added test case with copy on read
Reviewed-by-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refactor iotune verification, and verify some rules
* Disk iotune validation can be reused for throttle group validation,
refactor it into common method "virDomainDiskIoTuneValidate"
* Add "virDomainDefValidateThrottleGroups" to validate throttle groups,
which in turn calls "virDomainDiskIoTuneValidate"
* Make sure referenced throttle group exists
* Use "iotune" and "throttlefilters" exclusively for specific disk
* Throttle filters cannot be used together with CDROM
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Moved validation code from parser to validator
* Removed dead checks after validation
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For hot attaching/detaching
* Leverage qemuBlockThrottleFiltersData to prepare attaching/detaching
throttle filter data for qemuMonitorBlockdevAdd and qemuMonitorBlockdevDel
* For hot attaching, within qemuDomainAttachDiskGeneric,prepare throttle
filters json data, and create corresponding blockdev for QMP request
("blockdev-add" with "driver":"throttle")
* Each filter has a nodename, and those filters are chained up,
create them in sequence, and delete them reversely
* Delete filters by "qemuBlockThrottleFiltersDetach"("blockdev-del")
when detaching device
For throttle group commandline
* Add qemuBuildThrottleGroupCommandLine in qemuBuildCommandLine to add
"object" of throttle-group
* Verify throttle group definition when lauching vm
* Check QEMU_CAPS_OBJECT_JSON before "qemuBuildObjectCommandlineFromJSON",
which is to build "-object" option
For throttle filter commandline
* Add qemuBuildDiskThrottleFiltersCommandLine in qemuBuildDiskCommandLine
to add "blockdev"
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Apply suggested coding style changes.
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Removed QEMU_CAPS_OBJECT_JSON_CHECK
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It contains throttle filter nodename processing(new nodename,
topnodename, parse and format nodename), throttle filter
attaching/detaching preparation and implementation.
* Updated "qemuDomainDiskGetTopNodename", so if throttlefilter is used
together with copyOnRead, top node is throttle filter node, e.g.
device -> throttle -> copyOnRead Layer-> image chain
* In qemuBuildThrottleFiltersAttachPrepareBlockdev, if copy_on_read
is on, build throttle nodename chain on top of copy_on_read nodename
* In status xml, throttle filter nodename(virDomainDiskDef.nodename) is
saved at disk/privateData/nodenames/nodename(type='throttle-filter'),
corresponding parse/format sits in qemuDomainDiskPrivateParse and
qemuDomainDiskPrivateFormat
* If filter nodename hasn't been set by qemuDomainDiskPrivateParse,
in qemuDomainPrepareThrottleFilterBlockdev, filter nodename index
can be generated by reusing qemuDomainStorageIDNew and current
global sequence number is persistented in virDomainObj-
>privateData(qemuDomainObjPrivate)->nodenameindex.
qemuDomainPrepareThrottleFilterBlockdev is called by
qemuDomainPrepareDiskSourceBlockdev, which in turn used by both
hotplug and qemuProcessStart to prepare throttle filter node name
* Define method qemuBlockThrottleFilterGetProps, which is used by
both hotplug and command to build throttle object for QEMU
* Define methods for throttle filter attach/detach/rollback
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Apply suggested coding style changes.
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
ThrottleGroup lifecycle implementation, note, in QOM, throttlegroup name is prefixed with
"throttle-" to clearly separate throttle group objects into their own namespace.
* "qemuDomainSetThrottleGroup", this method is to add("object-add") or update("qom-set")
throttlegroup in QOM and update corresponding objects in DOM
* "qemuDomainGetThrottleGroup", this method queries throttlegroup info by groupname
* "qemuDomainDelThrottleGroup", this method checks if group is referenced by any throttle
in disks and delete it if it's not used anymore
* Check flag "QEMU_CAPS_OBJECT_JSON" during qemuDomainSetThrottleGroup when vm is active,
throttle group feature requries such flag
* "objectAddNoWrap"("props") check is done by reusing qemuMonitorAddObject in
qemuDomainSetThrottleGroup
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Apply suggested coding style changes.
* cleanup qemu Get ThrottleGroup.
* Update the version to 11.1.0.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Removed QEMU_CAPS_OBJECT_JSON check as the flag no longer exists.
* Update the version to 11.2.0.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
extract common methods from "qemuDomainSetBlockIoTune" to be reused
by throttle handling later, common methods include:
* "qemuDomainValidateBlockIoTune", which is to validate that PARAMS
contains only recognized parameter names with correct types
* "qemuDomainSetBlockIoTuneFields", which is to load parameters into
internal object virDomainBlockIoTuneInfo
* "qemuDomainCheckBlockIoTuneMutualExclusion", which is to check rules
like "total and read/write of bytes_sec cannot be set at the same time"
* "qemuDomainCheckBlockIoTuneMax", which is to check "max" rules within iotune
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Defined new public APIs:
* virDomainSetThrottleGroup to add or update throttlegroup within specific domain,
it will be referenced by throttlefilter later in disk to do limits
* virDomainGetThrottleGroup to get throttlegroup info, old-style is discarded
(APIs to query first for the number of parameters and then give it a
reasonably-sized pointer), instead, the new approach is adopted that
API returns allocated array of fields and number of fileds that are in it.
* virDomainDelThrottleGroup to delete throttlegroup, it fails if this throttlegroup
is still referenced by some throttlefilter
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Reimplement getter API to fetch data from XML.
* Apply suggested coding style changes.
* Update of code documentation comments.
* Update the version to 11.2.0.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Within "testQemuMonitorJSONqemuMonitorJSONUpdateThrottleGroup"
* Test qemuMonitorJSONGetThrottleGroup
* Test qemuMonitorJSONUpdateThrottleGroup, which updates limits through "qom-set"
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* fix test
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Deleted getter-related code.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This change contains QMP requests for ThrottleGroup
* ThrottleGroup is updated through "qemuMonitorJSONUpdateThrottleGroup"
* ThrottleGroup is retrieved through "qemuMonitorJSONGetThrottleGroup"
* ThrottleGroup is deleted by reusing "qemuMonitorDelObject"
* ThrottleGroup is added by reusing "qemuMonitorAddObject"
* "qemuMonitorMakeThrottleGroupLimits" will be used by building qemu cmd as well
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* change throttle group config conversions P to U allow zero.
* Apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Deleted all getter code.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce throttle filter along with corresponding operations.
* Define new struct 'virDomainThrottleFilterDef' and corresponding destructor
* Update _virDomainDiskDef to include virDomainThrottleFilterDef
* Support throttle filter "Parse" and "Format" for operations between DOM XML
and structs. Note, this commit just contains parse/format of group name for
throttle filter in domain_conf.c, there is other commit to handle throttle
filter nodename parse/format between throttlefilter and diskPrivateData for
statusxml in qemu_domain.c when processing qemuDomainDiskPrivate and
qemuDomainDiskPrivate
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Error handling for null throttle group.
* Update of code documentation comments.
* Apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Fixed naming of virDomainThrottleFilterDefClear to ...Free
* Fixed memleak of the throttle filter definitions
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce throttlegroup into domain and provide corresponding methods
* Define new struct 'virDomainThrottleGroupDef' and corresponding destructor
* Add operations(Add, Update, Del, ByName, Copy, Free) for 'virDomainThrottleGroupDef'
* Update _virDomainDef to include virDomainThrottleGroupDef
* Support new resource "Parse" and "Format" for operations between struct and DOM XML
* Make sure "group_name" is defined in xml
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Validation check for zero throttle groups.
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce schema for defining '<throttlefilters>' element which
references throttling groups to form filter chain in qemu for specific
disk
* Add new elements '<throttlefilters>'
* <ThrottleFilters> can include multiple throttlegroup references to
form filter chain in qemu
* Chained throttle filters feature in qemu is described at
https://gitlab.com/qemu-project/qemu/blob/master/docs/throttle.txt
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce schema for defining '<throttlegroups>' element which
configures throttling groups which can be configured for multiple
disks.
* Refactor "diskIoTune" to extract common schema "iotune"
* Add new elements '<throttlegroups>'
* <ThrottleGroups> contains <ThrottleGroup> defintion, which references
"iotune"
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add new virsh command 'hypervisor-cpu-models'. Command pulls from the
existing domcapabilities XML and uses xpath to parse CPU model strings.
By default, only models reported as usable by the hypervisor on the
host system are printed. User may specify "--all" to also print
models which are not supported on the host.
Signed-off-by: David Judkovics <djudkovi@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since processing running VMs on OS shutdown can take a while, it is
beneficial to send systemd status messages about the progress.
The systemd status is a point-in-time message, with no ability to
look at the history of received messages. So in the systemd status
we include the progress information. For the same reason there is
no benefit in sending failure messages, as they'll disappear as soon
as a status is sent for the subsequent VM to be processed.
The libvirt log statements can be viewed as a complete log record
so don't need progress info, but do include warnings about failures
(present from earlier commits).
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The service unit "TimeoutStopSec" setting controls how long systemd
waits for a service to stop before aggressively killing it, defaulting
to 30 seconds if not set.
When we're processing shutdown of VMs in response to OS shutdown, we
very likely need more than 30 seconds to complete this job, and can
not stop the daemon during this time.
To avoid being prematurely killed, setup a timer that repeatedly
extends the "TimeoutStopSec" value while stop of running VMs is
arranged.
This does mean if libvirt hangs while stoppping VMs, systemd won't
get to kill the libvirt daemon, but this is considered less harmful
that forcefully killing running VMs.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The daemons are wired up to shutdown in responsible to UNIX process
signals, as well as in response to login1 dbus signals, or loss of
desktop session. The latter two options can optionally preserve state
(ie running VMs).
In non-systemd environments, as well as for testing, it would be useful
to have a way to trigger shutdown with state preservation more directly.
Thus a new admin protocol API is introduced
virAdmConnectDaemonShutdown
which will trigger a daemon shutdown, and preserve running VMs if the
VIR_DAEMON_SHUTDOWN_PRESERVE flag is set.
It has a corresponding 'virt-admin daemon-shutdown [--preserve]' command
binding.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The preserving of state (ie running VMs) requires a fully functional
daemon and hypervisor driver. If any part has started shutting down
then saving state may fail, or worse, hang.
The current shutdown sequence does not guarantee safe ordering, as
we synchronize with the state saving thread only after the hypervisor
driver has had its 'shutdownPrepare' callback invoked. In the case of
QEMU this means that worker threads processing monitor events may well
have been stopped.
This implements a full state machine that has a well defined ordering
that an earlier commit documented as the desired semantics.
With this change, nothing will start shutting down if the state saving
thread is still running.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The call to preserve state (ie running VMs) is triggered in response to
the desktop session dbus terminating (session daemon), or logind sending
a "PrepareForShutdown" signal. In the case of the latter, daemons
should only save their state, not actually exit yet. Other things on the
system may still expect the daemon to be running at this stage.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the remote daemon code is responsible for calling virStateStop
in a background thread. The virNetDaemon code wants to synchronize with
this during shutdown, however, so the virThreadPtr must be passed over.
Even the limited synchronization done currently, however, is flawed and
to fix this requires the virNetDaemon code to be responsible for calling
virStateStop in a thread more directly.
Thus the logic is moved over into virStateStop via a further callback
to be registered by the remote daemon.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The next patch will be introducing a new callback, so rename the method
to virNetDaemonSetLifecycleCallbacks to reflect the more general usage.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It is not documented what the various virStateNNN methods are each
responsible for doing and the names give little guidance either.
Provide some useful documentation comments to explain the intended
usage of each.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If shutting down running VMs at host shutdown, it can be useful to
automatically start them again on next boot. This adds a config
parameter 'auto_shutdown_restore', which defaults to enabled, which
leverages the autostart once feature.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When performing auto-shutdown of running domains, there is now the
option to mark them as "autostart once", so that their state is
restored on next boot. This applies on top of the traditional
autostart flag.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is maintained in the same way as the autostart flag, using a
symlink. The difference is that instead of '.xml', the symlink
suffix is '.xml.once'.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When a domain is marked for autostart, it will be started on every
subsequent host OS boot. There may be times when it is desirable to
mark a domain to be autostarted, on the next boot only.
Thus we add virDomainSetAutostartOnce / virDomainGetAutostartOnce.
An alternative would have been to overload the existing
virDomainSetAutostart method, to accept values '1' or '2' for
the autostart flag. This was not done because it is expected
that language bindings will have mapped the current autostart
flag to a boolean, and thus turning it into an enum would create
a compatibility problem.
A further alternative would have been to create a new method
virDomainSetAutostartFlags, with a VIR_DOMAIN_AUTOSTART_ONCE
flag defined. This was not done because it is felt desirable
to clearly separate the two flags. Setting the "once" flag
should not interfere with existing autostart setting, whether
it is enabled or disabled currently.
The 'virsh autostart' command, however, is still overloaded
by just adding a --once flag, while current state is added
to 'virsh dominfo'.
No ability to filter by 'autostart once' status is added to
the domain list APIs. The most common use of autostart once
will be to automatically set it on host shutdown, and it be
cleared on host startup. Thus there would rarely be scenarios
in which a running app will need to filter on this new flag.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When doing managed save of VMs, triggered by OS shutdown, it may
be desirable to control cache usage.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Bypassing cache can make save performance more predictable and avoids
trashing the OS cache with data that will not be read again.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow users to control how many seconds libvirt waits for QEMU
shutdown before force powering off a guest.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the session daemon will try a managed save on all VMs,
leaving them running if that fails.
This limits the managed save just to persistent VMs, as there will
usually not be any way to restore transient VMs later.
It also enables graceful shutdown and then forced poweroff, should
save fail for some reason.
These new defaults can be overridden in the config file if needed.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently automatic VM managed save is only performed in session
daemons, on desktop session close, or host OS shutdown request.
With this change it is possible to control shutdown behaviour for
all daemons. A recommended setup might be:
auto_shutdown_try_save = "persistent"
auto_shutdown_try_shutdown = "all"
auto_shutdown_poweroff = "all"
Each setting accepts 'none', 'persistent', 'transient', and 'all'
to control what types of guest it applies to.
For historical compatibility, for the system daemon, the settings
currently default to:
auto_shutdown_try_save = "none"
auto_shutdown_try_shutdown = "none"
auto_shutdown_poweroff = "none"
while for the session daemon they currently default to
auto_shutdown_try_save = "persistent"
auto_shutdown_try_shutdown = "none"
auto_shutdown_poweroff = "none"
The system daemon settings should NOT be enabled if the traditional
libvirt-guests.service is already enabled.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It may be desirable to treat transient VMs differently from persistent
VMs. For example, while performing managed save on persistent VMs makes
sense, the same not usually true of transient VMs, since by their
nature they will have no config to restore from.
This also lets us fix a long standing problem with incorrectly
attempting to perform managed save on transient VMs.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The auto shutdown code can currently only perform managed save,
which may fail in some cases, for example when PCI devices are
assigned. On failure, shutdown inhibitors remain in place which
may be undesirable.
This expands the logic to try a sequence of operations
* Managed save
* Graceful shutdown
* Forced poweroff
Each of these operations can be enabled or disabled, but they
are always applied in this order.
With the shutdown option, a configurable time is allowed for
shutdown to complete, defaulting to 30 seconds, before moving
onto the forced poweroff phase.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the virStateStop method is only wired up to run save for
the unprivileged daemons, so there is no functional change.
IOW, session exit, or host OS shutdown will trigger VM managed saved
for QEMU session daemon, but not the system daemon.
This changes the daemon code to always run virStateStop for all
daemons. Instead the QEMU driver is responsible for skipping its
own logic when running privileged...for now.
This means that virStateStop will now be triggered by logind's
PrepareForShutdown signal.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a move of the code that currently exists in the QEMU
driver, into the common layer that can be used by multiple
drivers.
The code currently supports performing managed save of all
running guests, ignoring any failures.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Calls to 'qemuHotplugRemoveManagedPR' needed to be guarded by a check if
the removed elements actually caused us to add the manager in the first
place.
The two new calls added in commit 1697323bfe were
not guarded by such check and thus would spam the debug log with:
[{"id": "libvirt-59", "error": {"class": "GenericError", "desc": "object 'pr-helper0' not found"}}]
Luckily 'qemuHotplugRemoveManagedPR' didn't request the error to be
reported as a proper error.
Don't attempt the removal unless needed.
Fixes: 1697323bfe
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Do not use the rollback code path on success just to avoid extra call to
qemuHotplugRemoveManagedPR.
Rename the label and use it only when rolling back.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The only place which actually checked the return value would skip code
e.g. to delete unused files or stop no longer used services. The rest of
the callers ignored the value.
As this is expected to be used on cleanup code paths which have no
possibility to report errors we should remove the return value
completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The block copy operation is supposed to just move the disk to a new
destination. While in certain scenarios it'd make sense to drop the
copy-on-read layer, the definition would not correspond to it.
This was caused by a fix to the behaviour of the block job after
conversion to -blockdev as 'blockdev-mirror' requires the top node of
the disk to be selected. This also causes that the 'copy-on-read' filter
is ejected but libvirt doesn't unplug it.
Instead we need to use the 'replaces' argument of 'blockdev-mirror'
which allows to keep filters in place. This will preserve the
configuration (which can be optimized later) and also fixes a spurious
error logged when trying to unplug the first real file node after
copy-on-read which still looks used to qemu.
This is also needed for the upcoming feature which adds 'throttle'
filter layers as we need to keep those in place too to facilitate the
throttling.
Resolves: https://issues.redhat.com/browse/RHEL-40077
Fixes: e3137539a9
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The 'replaces' field controls which node will be replaced by the job.
This can be used to e.g. keep filter nodes in place after the copy
finishes.
This will be used to keep the 'copy-on-read' and 'throttle' layers in
place after a copy.
This patch wires up the monitor and test, but the real callers pass NULL
for now.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Test the XML and commandline for iothread<->virtqueue mapping for
'virtio-scsi' controllers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to 'virtio-blk' users can map multiple iothreads and pin them
appropriately for 'virtio-scsi' controllers to ensure the best
performance.
Implement the validation and command line generation based on the
helpers we have for 'virtio-blk'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming qemu release will support configuring mapping iothreads to
virtio queues for 'virtio-scsi' controllers in order to improve
performance.
Reuse the infrastructure we have from the same configuration for
'virti-blk' to implement the conf support for this feature.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'virtio-scsi' controller now supports iothread<->virtqueue mapping
configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since commit f23f8ff91a virtio-mem supports also CCW. When hotplugging a
virtio-mem device with a CCW address results in a PCI device getting
attached. The method qemuDomainAssignMemoryDeviceSlot is only
considering PCI as address type and overwriting the CCW address. Adding
support for address type CCW.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Wire the external server RDP support with QEMU.
Check the configuration, allocate a port, start the process
and set the credentials.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This will help with the following patch, which also requires config access.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The following changes are going to communicate with the qemu-rdp server
through the VM D-Bus bus, keep a connection for that and further usage.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Helps avoid/debug a potential SEGV if conn is NULL, since gio will not
set the "gerror" in that case and we will crash later at:
virReportError(VIR_ERR_DBUS_SERVICE, "%s", gerror->message);
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When compiled with -Doptimization=g
../tools/nss/libvirt_nss_macs.c:155:8: error: ‘jerr’ may be used uninitialized [-Werror=maybe-uninitialized]
155 | if (jerr == json_tokener_continue) {
| ^
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The warning is triggered when compiling with various build options, such
as -Doptimization=g.
From gcc(1) man page about -Winline:
seemingly insignificant changes in the source program can cause the warnings produced by -Winline to appear or disappear.
Such flaky behaviour is best left to the user discretion.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Introduce a new ninja target
ninja -C build regen-{PROTO}
eg
ninja -C build regen-admin_protocol
that will re-create the reference output file based on what the
current pdwtags command emits. A small change is made to squash
whitespace on enum declarations so that introducing a new longer
enum name doesn't trigger re-indent of all existing enum names.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This makes the output match what current pdwtags will emit,
modulo some whitespace changes made by the check script
before comparison.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When event handler thread is created inside of
virCHStartEventHandler() the monitor object is refed because the thread
(virCHEventHandlerLoop()) that's created in the very next step
uses it. But right after that, the monitor object is unrefed,
which is wrong because it takes away the reference which was
handed over to the thread. The monitor must be unrefed inside the
thread, when no longer needed.
And while at it, move the unref call of the domain object after
the debug print which obviously accesses the domain definition.
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If starting a CH domain fails an error is reported and
virCHProcessStart() calls virCHProcessStop() to clean up any
residues. Problem is, inside of virCHProcessStop() some public
APIs might be called (e.g. virNetworkLookupByName(),
virNetworkPortLookupByUUID() and/or virNetworkPortDelete()). Per
our design, public APIs reset last error which means the useful
error reported earlier is lost.
Fix this by calling virErrorPreserveLast() + virErrorRestore()
combo inside of virCHProcessStop().
Signed-off-by: Kirill Shchetiniuk <kshcheti@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The glib adoption docs was suggesting avoidance of certain APIs that
were obsoleted by glib, during the transition period. Now that the
referenced APIs no longer exist in libvirt code, they can also be
removed from the docs.
NB, the virStringListRemoveDuplicates method remains since there is
no glib equivalent.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Most, but not all, files in scripts have execute permission. While we
don't need this in order to launch them via meson/ninja build rules,
it is nice to direct execution if they have execution permission. This
makes the practice consistent across all scripts.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If a contributor's email domain has a DMARC policy of 'p=quarantine'
or 'p=reject', mailman will apply DMARC countermeasures on all mails
sent to lists.libvirt.org rewriting the "From" header to remove the
sender's email address. e.g.
From: Your Name via <lists.libvirt.org>
If these countermeasures were not applied, affected mail would either
have gone directly to SPAM, or have been entirely rejected. Mailman3
is unable to be configured to guarantee no mangling of the mail body
so these countermeasures are unavoidable for lists.libvirt.org.
Amongst the various downsides, the From address rewriting has the
bad effect of mangling git commit author attribution.
To avoid this it is required to add two additional git config
settings:
$ git config --global format.from "Your Name <your@email.com>"
$ git config --global format.forceInBodyFrom true
Note, *both* are required, even if your ``format.from`` matches
your existing git identity, because the latter only takes effect
once the former is set.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The original implementation of the passt backend for vhost-user
interfaces erroneously forgot to parse:
<source dev='blah'/>
for interface type='vhostuser', so it wasn't being added to the passt
commandline, and also wasn't being saved to the domain config. Now we
parse it whenever the <backend> type='passt', no matter what the
interface type, and then throw an error during validation if
source/@dev was specified for interface type = 'user|vhostuser' and
backend type != 'passt'.
Fixes: 1e9054b9c7
Resolves: https://issues.redhat.com/browse/RHEL-82539
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Clarify what source and name attributes of TPM profile describe and
update the version placeholder to the libvirt version when profiles
were first supported, v10.10. Also mention that profiles with prefix
'custom:' in their name can be modified.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Firstly, let's switch from explicit virCHDriverGetConfig() +
virObjectUnref() combo to g_autoptr(virCHDriverConfig). This
leaves us with the @monitor variable which is initialized to NULL
only to be then set to the retval of virCHMonitorNew() and
returned instantly. Well, the variable is now useless and can be
dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
At the beginning of virCHProcessStop() the ref to driver config
is obtained (via virCHDriverGetConfig()), but corresponding unref
call is lacking. Use g_autoptr() to make sure the config is
unrefed always.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When the CH driver starts a domain virCHProcessSetupIOThreads()
is called eventually which in turn calls
virCHMonitorGetIOThreads(). The latter returns an array of
iothreads which is never freed leading to a memleak:
130 (104 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 1,804 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0xB3A9359: virCHMonitorGetIOThreads (ch_monitor.c:1183)
by 0xB3AA5BB: virCHProcessSetupIOThreads (ch_process.c:348)
by 0xB3AAC59: virCHProcessSetup (ch_process.c:480)
by 0xB3AC75A: virCHProcessStart (ch_process.c:973)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
by 0x4B1FB99: virNetServerProgramDispatch (virnetserverprogram.c:299)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are some members of the virCHDomainObjPrivate struct that
are allocated at various stages of domain lifecycle but then are
never freed:
1) cgroup - allocated in virDomainCgroupSetupCgroup()
2) autoCpuset - this one is actually never allocated (and thus is
always NULL, but soon it may be used. Just free
it for now, which is a NOP anyways.
3) autoNodeset - same story as 2).
There are two more members, which shouldn't be freed:
1) driver - this is just a raw pointer to the CH driver (see
virCHDomainObjPrivateAlloc()).
2) monitor - this member is cleared in virCHProcessStop(), way
before control even gets to
virCHDomainObjPrivateFree().
452 (400 direct, 52 indirect) bytes in 1 blocks are definitely lost in loss record 1,944 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0x49479CE: virCgroupNewFromParent (vircgroup.c:893)
by 0x49481BA: virCgroupNewDomainPartition (vircgroup.c:1068)
by 0x494915E: virCgroupNewMachineManual (vircgroup.c:1378)
by 0x49492FE: virCgroupNewMachine (vircgroup.c:1432)
by 0x4B5E3DE: virDomainCgroupInitCgroup (domain_cgroup.c:377)
by 0x4B5E9CD: virDomainCgroupSetupCgroup (domain_cgroup.c:524)
by 0xB3AC693: virCHProcessStart (ch_process.c:951)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are two places where curl_slist_append() is called but
corresponding call to curl_slist_free_all() is missing:
virCHMonitorPutNoContent() and virCHMonitorGet() which leads to
memleaks:
41 (16 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 992 of 1,998
at 0x4845888: malloc (vg_replace_malloc.c:446)
by 0x5B2F8FE: curl_slist_append (in /usr/lib64/libcurl.so.4.8.0)
by 0xB3A7B41: virCHMonitorPutNoContent (ch_monitor.c:824)
by 0xB3A89FF: virCHMonitorBootVM (ch_monitor.c:1030)
by 0xB3AC6F1: virCHProcessStart (ch_process.c:967)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
by 0x4B1FB99: virNetServerProgramDispatch (virnetserverprogram.c:299)
by 0x4B28B5E: virNetServerProcessMsg (virnetserver.c:135)
88 (16 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 1,501 of 1,998
at 0x4845888: malloc (vg_replace_malloc.c:446)
by 0x5B2F8FE: curl_slist_append (in /usr/lib64/libcurl.so.4.8.0)
by 0xB3A7E41: virCHMonitorGet (ch_monitor.c:864)
by 0xB3A92E2: virCHMonitorGetInfo (ch_monitor.c:1157)
by 0xB3A9CEA: virCHProcessUpdateInfo (ch_process.c:142)
by 0xB3AAD36: virCHProcessSetup (ch_process.c:492)
by 0xB3AC75A: virCHProcessStart (ch_process.c:973)
by 0xB39B7D4: chDomainCreateXML (ch_driver.c:246)
by 0x4CC9D32: virDomainCreateXML (libvirt-domain.c:188)
by 0x168F91: remoteDispatchDomainCreateXML (remote_daemon_dispatch_stubs.h:5186)
by 0x168F18: remoteDispatchDomainCreateXMLHelper (remote_daemon_dispatch_stubs.h:5167)
by 0x4B20066: virNetServerProgramDispatchCall (virnetserverprogram.c:423)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The shutdown inhibitor is created in networkStateInitialize() but
corresponding call to virInhibitorFree() is missing in
networkStateCleanup() leading to a memleak:
116 (72 direct, 44 indirect) bytes in 1 blocks are definitely lost in loss record 1,769 of 1,998
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F0E7A9: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8000.5)
by 0x4993B9B: virInhibitorNew (virinhibitor.c:152)
by 0x5279394: networkStateInitialize (bridge_driver.c:654)
by 0x4CC74DC: virStateInitialize (libvirt.c:665)
by 0x15B719: daemonRunStateInit (remote_daemon.c:613)
by 0x49F2B44: virThreadHelper (virthread.c:256)
by 0x5356662: start_thread (in /usr/lib64/libc.so.6)
by 0x53D7DA3: clone (in /usr/lib64/libc.so.6)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The 'transform' attribute of 'bitmaps' was added in qemu-6.0, thus
we can assume all qemus we're willing to use support it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
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>
While we show the example in the docs we don't have an example XML for
exercising the parser/formatter and schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an example for the automatic/round-robin mapping of iothreads which
users should preferrably use. Until now the example contained even the
full mapping which could push users to use that instead.
Mention that the queues are then automatically distributed among the
iothreads.
Also clarify the need to set 'queues' when mapping threads explicitly
and how the queues are identified.
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>
The vhost-user protocol requires shared memory support to work properly.
Our test XMLs didn't have it configured as for interface the check if
shared memory is present only produces a warning instead of a proper
error.
Upcoming patches will be moving the check to become fatal so the test
cases need to be fixed first.
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>
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>
Only VNC, RDP and Spice graphics types are using listen elements so call
the function only where it is needed.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This will be used in specific graphics types that are using listen
elements.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virDomainGraphicsDefFormat function was way too long so split it into
separate functions for each graphics type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virDomainGraphicsDefFormat function was way too long so split it into
separate functions for each graphics type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virDomainGraphicsDefFormat function was way too long so split it into
separate functions for each graphics type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virDomainGraphicsDefFormat function was way too long so split it into
separate functions for each graphics type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virDomainGraphicsDefFormat function was way too long so split it into
separate functions for each graphics type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virDomainGraphicsDefFormat function was way too long so split it into
separate functions for each graphics type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virDomainGraphicsDefFormat function was way too long so split it into
separate functions for each graphics type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use separate buffers for attributes and children elements to make the
code cleaner and to use the virXMLFormatElement() function.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This fixes representation of the 'acpi_firmware' config in the Xen
driver, which repesents a concatenation of tables of any type.
Use of 'type=slic' is accepted on input for backwards compatibility.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This allows passing a single ACPI table of any type through to QEMU with
the signture autodetected from the header.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The QEMU driver has only accepted type=slic even though QEMU is able to
accept individual tables of any type, without needing to specify a
signature. Introduce type=raw to address this usage scenario. Contrary
to other types, this one may appear multiple times.
The Xen driver has mistakenly accepted type=slic and use it to set the
Xen acpi_firmware setting, which performs a simple passthrough of
multiple concatenated data table. Introduce type=rawset to address
this usage scenario.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This forces us to update the drivers when defining new table types
to avoid incorrectly accepting them by default.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently we parse
<os>
<acpi>
<table type="slic">...path...</table>
</acpi>
</os>
into a flat 'char *slic_table' field which is rather an anti-pattern
as it has special cased a single attribute type.
This rewrites the internal design to permit multiple table types to
be parsed, should we add more in future. Each type is currently
permitted to only appear once.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The `nwfilterBindingCreateXML` and `nwfilterConnectListAllNWFilters`
APIs can acquire locks on multiple instances of virNWFilterObj. There
is no guarantee they will acquire these locks in the same order as
each other. Thus there is a potential for deadlock if they run
concurrently acquiring locks on the same filter objects.
This flaw has always existed, but historically was rare, because
virNWFilterObjList previously used an array. This meant iteration
over filters had a fixed order, matching order of loading filters
into libvirt. The set of filter references would have to be just
right to expose the lock ordering deadlock.
In 8.2.0, commit c4fb52dc72 switched
to use a hash table, introducing non-determinism to the iteration
order, as hash buckets vary based on the hash seed. As such almost
any filter with references is exposed to the deadlock risk now.
It is not easy to guarantee lock ordering on the virNWFilterObj
instances, so acquiring `driverMutex` first, will serve to serialize
all lock acquisition on virNWFilterObj instances, avoiding the
deadlock scenario.
The major cost is that concurrency of the driver is significantly
reduced, with few other APIs able to run in parallel with updating
firewall rules.
A long term solution to this problem needs significant changes
* The mutex on virNWFilterObj would need to change to a R/W
lock.
* The filter instantiation/teardown process would need to split
into two phases. The first phase would resolve all the required
virNWFilterObj instances & acquire read locks, while holding
the 'driverMutex'. The second phase of running iptables/ebtables
commands would then run without driverMutex held.
* The filter define/undefine APIs would need to acquire write
locks, other APIs only read locks.
This would allow concurrency of filter instantiation/teardown
with everything except for filter defnie/undefine, which was
the original desire.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[DPB: rewrite commit message & add inline comment]
Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
qemuSnapshotDeleteBlockJobFinishing() returns only 0 and 1. Convert it
to bool and remove the dead code handling -1 return in the caller.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Reported-by: Reported-by: Andrey Slepykh <a.slepykh@fobos-nt.ru>
Signed-off-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The combination of italics and the since tag does not work together.
Remove it from the paragraph about using passt with vhostuser,
as well as the parentheses around it.
Signed-off-by: Yalan Zhang <yalzhang@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Freeing the 'virSEVCapability' object leaked the 'cpu0_id' field since
its introduction.
Fixes: 0236e6154c
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
While the 'launch-security-sev-direct' and 'launch-security-sev-snp'
cases use "latest" caps, they use the non-sev variant and add-in the
relevant capabilities.
To do the test properly we can add '+amdsev' variant which uses caps
fetched from a real host that does support all the capabilities.
The output files are identical, although they are not added as symlinks
to prevent headaches if they do diverge at some point.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The 'launch-security-sev' and
'launch-security-sev-missing-platform-info' tests run agains the
qemu-6.0.0 caps which were manually doctored to support SEV.
Since we now have the '+amdsev' variant dumped from a more modern qemu
add another invocation of the tests.
The only relevant difference in the output data is 'cbitpos' being '51'
on the new platform, for the test case which explicitly doesn't
configure it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
While the 'qemuxmlconftest' was able to load capability variants the
output file name didn't include the variant thus it was not possible to
test the same input file both on the default variant and on an explicit
variant.
Include the variant in the output file name and adjust two output file
names.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Introduce the test data as 'qemu_9.2.0.x86_64+amdsev' to test
SEV-related capability code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Upcoming patch will introduce test data from an SEV-enabled host.
Document the new variant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Currently only the default variant ("") and "+hvf" are present in our
test data but upcoming patches will add another variant.
Upcoming test variants may not require any special handling so we should
be able to handle them using the default code path now that 'variant' is
properly propagated inside the test code.
Remove the restriction to test only the default ("") and "+hvf" variant
and modify the documentation to state that any other variant is tested
the same way as the default one.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The qemu part of 'domaincapstest' supports testing of the '+hvf' variant
of files, but doesn't properly pick the input file. The input file lacks
the variant part thus the wrong file is used.
Propagate the variant and select the correct input file.
Fixes: 738c5bae88
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The 'cpu0Id' field is formatted into the caps cache XML but not parsed
back; thus restart of the daemon will make it vanish.
Fixes: 0236e6154c
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This function can't fail, but it has always returned 1 if a controller
is added and 0 if not, and there is one place that checks for a 1
return, so we remove the -1 return and change it to return true/false
instead of 1/0.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
It can't fail. And as a result, hypervDomainDefAppendSCSIController() and
hypervDomainDefAppendIDEController() can also be changed to return void.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
It can't fail, so the caller doesn't need to check the return.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
It can't fail, so the caller doesn't need to check the return.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
On current Fedora libvirt uses nftables by default but the libvirt-tck
tests are not ready for it and most of the nwfilter tests fail. We need
to keep using iptables for now.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit af1b89d1d for some reason changed a perfectly fine statement to
one that I could not understand. Let's revert it.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
virDomainHostdevDefNew() has been using g_new0() for a while now. As it
calls abort() on OOM, it's not necessary to check whether
the return value is NULL.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Add support for the 'image_format' typed parameter in virDomainSaveParams.
The parameter overrides the 'save_image_format' setting in qemu.conf.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add a new VIR_DOMAIN_SAVE_PARAM_IMAGE_FORMAT typed parameter for
specifying the save image format. A format specified via the
virDomainSaveParams API overrides the save_image_format setting
in qemu.conf. The 'raw' format remains the default.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Checking for valid 'foo_image_format' settings in qemu.conf is not done
until the settings are used. Move the checks to
virQEMUDriverConfigLoadSaveEntry, allowing to report incorrect format
settings at driver startup.
This change was made easier by also changing the corresponding fields
in the virQEMUDriverConfig to 'int', which is more in line with the
other fields that represent enumerated types.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
qemuSaveImageGetCompressionProgram is a bit overloaded. Along with
getting a compression program, it checks the validity of the image
format and returns the integer representation of the format. Change
the function to only handle retrieving the specified compression
program, returning success or failure. Checking the validity of
the image format can be left to the calling functions.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Long ago, without justification, commit 48cb9f0542 changed
qemuGetCompressionProgram (since renamed to
qemuSaveImageGetCompressionProgram) to ignore configuration errors
for dump operations. Like the other save-related operations, user
provided configuration should be verified and an error reported if
it cannot be honored.
Remove the special handling of configuration errors in
qemuSaveImageGetCompressionProgram and change the dump logic to
fail when dump image format cannot be supported.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In case when user provides custom paths (those not covered by the JSON
firmware descriptor files or the default locations) for the
loader and nvram template no auto-detection will be performed and user's
config will be taken at face value. Historically when 'templateFormat'
didn't exist we assumed that the 'format' field covers both.
Thus if 'templateFormat' is VIR_STORAGE_FILE_NONE we need to skip the
check forbidding image format conversion for 'file' backed to avoid
breaking legacy configs with manual/non-detected format assuming that
user picked the correct format.
Add a comment to the declaration of 'nvramTemplateFormat' noting the
above for future reference.
Resolves: https://issues.redhat.com/browse/RHEL-81731
Fixes: 2aa644a2fc
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Do not copy the <metadata> node to domain/network definition
if its empty.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Originally present in virDomainDefSetMetadata it got copied to
virNetworkDefSetMetadata too.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'Network' has one more letter than 'Domain' where these helpers
were copied from. Shift the unaligned lines by one.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that the refactor was completed the helper infrastructure can be
removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Also remove stale TODO comment as we already report disk target.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use of raw typed param APIs is very clunky. Prepare
qemuDomainGetGuestInfo for step-by-step refactor to virTypedParamList.
The two lists will coexist until the refactor is complete.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With qemu guest agent 9.3 we are able to get the load averages with a
new command.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
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: Martin Kletzander <mkletzan@redhat.com>
If SGX memory model is configured for domain then we need to
allow QEMU access some additional files:
1) /dev/sgx_vepc needs to be RW
2) /dev/sgx_provision needs to be RO
We already do this in SELinux driver but not in AppArmor.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/751
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When virCPUx86UpdateLive checks whether a feature was added to a CPU
model after the model was already released (vmx-* features in most Intel
models), the following assert could be logged by glib:
g_strv_contains: assertion 'strv != NULL' failed
While most of our CPU models have a non-empty list of added feature, new
models added in 2024 and versioned variants of older models have
addedFeatures == NULL.
Fixes: e622970c87
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Only libvirtd uses virtd_t/virt_exec_t context, modular daemons use
their specific context each.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
To make sure both error and warning messages printed by virsh are
properly marked for translation.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The prohibit_newline_at_end_of_diagnostic syntax check is confused when
another unrelated translatable message with a newline is too close to
the function it is supposed to check. Refactoring the code to make the
two strings further apart seems like the easiest solution.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Having to put a newline at the end of each debug message in virsh has
always felt strange.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
While using host CPU definition from capabilities XML is allowed for
historical reasons, it will likely provide incorrect results and should
be avoided.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This new function can be used for printing warnings about suboptimal
usage.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The code is moved into a newly introduced generic vshPrintStderr and
vshError changed into a tiny wrapper.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The same message was formatted both in vshOutputLogFile and in vshDebug
and vshError functions. This patch refactor vshOutputLogFile and its
callers to only format each message once.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using host CPU definition with hypervisor-cpu-baseline is possible, but
it provide incorrect results and thus it should not be documented the
same way we describe the correct usage. Also using host-model CPU from
domain capabilities was not described clearly enough.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using host CPU definition with hypervisor-cpu-compare is possible, but
it provide incorrect results and thus it should not be documented the
same way we describe the correct usage. Also using host-model CPU from
domain capabilities was not described clearly enough.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
I first noticed a problem when I added a <memoryBacking> element at an
unusual (but still correct) place in the domain XML, and validation
failed. Then I tried adding that element in several different places
and it failed in many, but not all of them.
(NB: from here on, I will use '' for the names of attributes in the
domain XML, <> for elements in the domain XML, and "" for the names of
grammar rule definitions in the RNG file, and "<>" for the names of
elements in the RNG file's own XML. Confused yet? If so, please tell
me a better way - everything I know about RNG I've picked up
informally by looking at examples in already existing RNG files)
Starting from the top level of the grammar for <domain>
("domaincontents" in domaincommon.rng), I noticed that
1) the "<attribute>" for the 'id' attribute of <domain> is defined
inside an "<interleave>" down in the definition of "ids" (which is
referenced from "domaincontents") (I'm not familiar with the
nomenclature - does that make it a "sub-grammer", "child-grammar",
???)
2) although the definition of "ids", had all of its
"<attribute>"s/"<element>"s inside an "<interleave>",
"domaincontents" already had the reference to "ids" inside an
"<interleave>", so there were nested "<interleave>"s.
It's not clear to me how an "<attribute>" or "<interleave>" inside
another "<interleave>" is supposed to behave, but they both seemed a
bit suspicious.
I tried all of the below modifications:
1) moving the grammar for the 'id' attribute out of the "<interleave>"
but still inside "ids"
2) moving the grammer for the 'id' attribute directly into
"domaincontents" (and outside of its "interleave"
3) removing the "<interleave>" that was inside "ids"
4) (2) + (3)
5) move the entire grammar rule "ids" up directly in place of <ref
name="ids"> in "domaincontents".
6) (5), but with the grammar for the 'id' attribute moved outside of
the "<interleave>"
(6) was the only change that allowed all of the following (using
modifications to the subelements of <domain> in
net-vhostuser-passt.xml as example):
a) a <memoryBacking> element in between *any* two existing elements
b) moving <name> in between any two elements
c) oddly, in addition to the problem with putting <memoryBacking> in
odd places, I also found that the original RNG did not allow the
<clock> element to be placed in between <on_poweroff> and
<on_reboot>, but once I'd made the change in (6), this was no
longer problematic. Why should this have any effect? No idea, but
it works :-/
(NB: there are many other cases of referencing "sub-grammar" from
inside an "<interleave>", and they all seem to work just fine;
possibly in this case it was problematic because the sub-grammar a)
also contained an "<interleave>", b) had an "<attribute>" at its
toplevel, or c) had multiple "<element>"s.)
(inexplicably (to me) at one point during my experimentation, I tried
reordering the references to "clock", "resources", "features", and
"events", and that *also* made it legal to put a <clock> element in
between the <on_*> elements:-O)
Since I was no longer able to reproduce the error described in (c)
once I had made mod (6) (move all of "ids" directly into
"domaincontent", I decided it was pointless for me to spend any more
time randomly poking and just add that to the new test case for that
in case some other random change to the RNG causes it to start failing
again.
(I thought of writing a test program that would try all possible
orderings of the subelements of <domain>, but since doing that for
even 10 subelements would mean testing > 3.2 million different XML
documents, I decided we could continue in this adhoc manner, just
adding a single new test case if/when a new validation failure is
found.)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As is often the case with macros (especially those that resolve to
multiple statements), it isn't technically necessary to end any of the
invocations of the DO_TEST_*() macros with a semicolon (as evidenced
by the lines changed in this path). Having does make some
auto-indenters (e.g. cc-mode in emacs) more likely to do the right
thing, though, and it also looks nicer if all the lines are similar.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The documentation states:
``iothread``
Supported for controller type ``scsi`` using model ``virtio-scsi`` for
``address`` types ``pci`` and ``ccw`` :since:`since 1.3.5 (QEMU 2.4)`. The
The code itself didn't validate if iothread is specified for any other
controller type.
Add test case showing the issue on one example.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The schema definition will be reused when adding iothread<->virtqueue
mapping for 'virtio-scsi'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function reports libvirt errors so stick with the usual '0' and '-1'
return values.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract the code to 'qemuDomainValidateIothreadMapping'. It will be
reused to validate the mapping for 'virtio-scsi' iothreads.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prepare for reuse of the code for 'virtio-scsi' controller.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code will be also needed for 'virtio-scsi' controller definitions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code will be also needed for 'virtio-scsi' controller definitions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The iothread mapping will be also possible for 'virtio-scsi' controllers
so rename the corresponding structs to a generic name.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When starting a VM with a vhost-user interface in server mode qemu will
wait for the incoming connection without running CPUs. This isn't really
documented in our XML. Additionally when hotplugging the same interface
the above will not happen.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Note that 'block' backed NVRAM may need to use 'qcow2' images to work
properly and that populating from template may not support format
conversion.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The presence of a return value made it seem that it's expected to fail
on errors which is not the case. The function is designed to skip
anything it can't fill and not fail when fetching individual stats.
Convert the workers to void to make it clear that it's expected not
to fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bulk domain stats API is meant to collect as much data as possible
without erroring out.
If fetching of the dirty rate stats fails just skip outputting them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bulk domain stats API is meant to collect as much data as possible
without erroring out.
If fetching of the memory bandwidth stats fails just skip outputting them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bulk domain stats API is meant to collect as much data as possible
without erroring out. Ignore errors from 'qemuDomainGetIOThreadsMon()'
and skip the data if an error happens.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bulk domain stats API is meant to collect as much data as possible
without erroring out. Skip the perf stats if we can't fetch them instead
of erroring out.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function didn't comply with libvirt's error reporting scheme as it
reported libvirt errors only sometimes. As callers may want to ignore
errors convert it to returning -errno on failure instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bulk domain stats API is meant to collect as much data as possible
without erroring out.
If fetching of the cache stats fails just skip outputting them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use g_autofree for the temporary variables, remove error checks for
virBitmapFormat and simplify formatting of multiple attributes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Decrease scope of temporary variables so that they don't have to be
autofreed and VIR_FREE()d at the same time.
Remove unneeded checks and temporary variables.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
NULL can't be returned; don't mention it in the docs.
Avoid extra cofusing variable when returning copy of empty string.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'qemuDomainStorageAlias' always returns non-NULL pointer if it gets a
non-NULL string on input. Remove unneeded checks from callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These files pollute the stderr output when the sc_trailing_blank
syntax check fails.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A function was changed from having no arguments to having a single
argument, but the entire body of the function was #ifdefed out for
windows builds, leaving that new argument unused. Surprisingly this
didn't cause the build to fail, but I happened to notice it flit by
during an rpm build.
Fixes: 785cd56e58
Signed-off-by: Laine Stump <laine@redhat.com>
In virFileIsSharedFSOverride() we compare a path against a list
of overrides looking for a match.
All overrides are canonicalized ahead of time though, so e.g.
/var/run/foo will be turned into /run/foo due to /var/run being
a symlink on modern Linux systems. But the path we're trying to
match with the overrides doesn't get the same treatment, so in
this scenario the comparison will always fail.
Canonicalizing the path as well solves the issue.
Resolves: https://issues.redhat.com/browse/RHEL-79165
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Almost everything is already there (in the section for using passt
with type='user'), so we just need to point to that from the
type='vhostuser' section (and vice versa), and add a bit of glue.
Also updated a few related details that have changed (e.g. default
model type for vhostuser is now 'virtio', and source type/mode are now
optional), and changed "vhost-user interface" to "vhost-user
connection" because the interface is a virtio interface, and
vhost-user is being used to connect that interface to the outside.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This can/should also be done for a traditional vhost-user interface
(ie not backend type='passt') but that will be a separate change.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
<interface type='vhostuser'><backend type='passt'/> needs to run the
passt command just as is done for interface type='user', but then add
vhostuser bits to the qemu commandline/monitor command.
There are some changes to the parsing/validation along with changes to
the vhostuser codepath do do the extra stuff for passt. I tried
keeping them separated into different patches, but then the unit test
failed in a strange way deep down in the bowels of the commandline
generation, so this patch both 1) makes the final changes to
parsing/formatting and 2) adds passt stuff at appropriate places for
vhostuser (as well as making a couple of things *not* happen when the
passt backend is chosen). The result is that you can now have:
<interface type='vhostuser'>
<backend type='passt'/>
...
</interface>
Then as long as you also have the following as a subelement of
<domain>:
<memoryBacking>
<access mode='shared'/>
</memoryBacking>
your passt interfaces will benefit from the greatly improved
efficiency of a vhost-user data path, and all without requiring
special privileges or capabilities *anywhere* (i.e. it works for
unprivileged libvirt (qemu:///session) as well as privileged libvirt).
Resolves: https://issues.redhat.com/browse/RHEL-69455
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When passt is used with vhostuser, the vhostuser code that builds the
qemu commandline will need to have the same socket path that is given
to the passt command, so this patch makes it visible outside of
qemu_passt.c.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuProcessPrepareDomain()'s comments say that it should be the only
place to change the "live XML" of a domain (i.e. the public parts of
the virDomainDef object that is shown in the domain's status
XML), and that seems like a reasonable idea (although there aren't
many users of it to date).
qemuProcessPrepareDomainNetwork() is called by the aforementioned
qemuProcessPrepareDomain() - this patch changes the "if (type ==
HOSTDEV)" in that function to a "switch(type)" so it's simpler to add
DomainDef modifications for various other types of virDomainNetDef,
and also so that anyone who adds a new interface type is forced to
look at the code and decide if anything needs to be done here for the
new type.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For some reason, when vhostuser interface support was added in 2014,
the parser required that the XML for the <interface> have a <source>
element with type, mode, and path, all 3 also required. This in spite
of the fact that 'unix' is the only possible valid setting for type,
and 95% of the time the mode is set to 'client' (as I understand from
comments in the code, normally a guest will use mode='client' to
connect to an existing socket that is precreated (by OVS?), and the
only use for mode='server' is for test setups where one guest is setup
with a listening vhostuser socket (i.e. 'server') and another guest
connects to that socket (i.e. 'client')). (or maybe one guest connects
to OVS in server mode, and all the others connect in client mode, not
sure - I don't claim to be an expert on vhost-user.)
So from the point of view of existing vhost-user functionality, it
seems reasonable to make 'type' and 'mode' optional, and by default
fill in the vhostuser part of the NetDef as if they were 'unix' and
'client'.
In theory, the <source> element itself is also not *directly* required
after this patch, however, the path attribute of <source> *is*
required (for now), so effectively the <source> element is still
required.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since vhostuser is only used/supported by the QEMU driver, and all the
rest of the vhostuser-specific validation is done in QEMU's
validation, lets move the final check (to see if they've tried to
enable auto-reconnect when this interface is on the server side of the
vhostuser socket) to the QEMU validate.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both vdpa and vhostuser require that the guest device be virtio, and
for interface type='vdpa', we already set <model type='virtio'/> if it
is unspecified in the input XML, so let's be just as courteous for
interface type='vhostuser'.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both vhostuser and vdpa interface types must use the virtio model in
the guest (because part of the functionality is implemented in the
guest virtio driver). Due to ["because that's the way it happened"]
this has been validated for vhostuser in the hypervisor-agnostic
validate function, but for vdpa it has been done in the QEMU-specific
validate. Since these interface models are only supported by QEMU
anyway, validate for both of them in the QEMU validation function.
Take advantage of this change to switch to using
virDomainNetIsVirtioModel(net) instead of "net->model ==
VIR_DOMAIN_NET_MODEL_VIRTIO" (the former also matches
...VIRTIO_TRANSITIONAL and ...VIRTIO_NON_TRANSITIONAL, so is more
correct).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Because all the checks for VIR_DOMAIN_NET_TYPE_VDPA were inside an
else-if clause that was immediately followed by another else-if clause
that forbid setting guestIP.ips or guestIP.routes, we've been allowing
users to set guestIP.* for vdpa interfaces (but then not doing
validation of the attributes that should have been done if we *did*
support setting IPs for vdpa (but we don't anyway, so 🤷.)
This can be fixed by turning the vdpa else-if clause into a top-level
if - this way vdpa interfaces will hit the "else if
(net->guestIP.nips)" clause and reject guest-side IP address setting.
Also, since there are currently *no* interface types for QEMU that
support adding guest-side routes, we put that check by itself (I think
it may be possible to set some guest routes for passt interfaces, but
we don't do that)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We haven't checked for memalloc failure in many years, and that was
the only reason this function would have ever failed.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When a daemon (like libvirtd, virtqemud, etc.) is started as an
unprivileged user (which is exactly how KubeVirt does it), then
it tries to register on both session and system DBus-es so that
it can shut itself down (e.g. when system is powering off or user
logs out). It's worth noting that this is just opportunistic and
if no DBus is available then no error is reported.
Or at least that's what we thought. Because the way our
virGDBusGetSessionBus() and virGDBusGetSystemBus() are written an
error is actually reported every time the daemon starts.
Use virGDBusHasSessionBus() and virGDBusHasSystemBus() to check
if corresponding bus is available.
Resolves: https://issues.redhat.com/browse/RHEL-79088
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This is just like virGDBusHasSystemBus() except it checks for the
session bus instead of the system one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This allows a user specified delay between autostart of each VM, giving
parity with the equivalent feature of libvirt-guests.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This delay can reduce the CPU/IO load storm when autostarting many
guests.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This eliminates some duplicated code patterns aross drivers.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There's a common pattern for autostart of iterating over VMs, acquiring
a lock and ref count, then checking the autostart & is-active flags.
Wrap this all up into a helper method.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Switch to the 'notify-reload' service type and send notifications to
systemd when reloading configuration.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We have a way to notify systemd when we're done starting the daemon.
Systemd supports many more notifications, however, and many of them
are quite relevant to our needs:
https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html
This renames the existing notification API to better reflect its
semantics, and adds new APIs for reporting
* Initiation of config file reload
* Initiation of daemon shutdown process
* Adhoc progress status messages
* Request to extend service shutdown timeout
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A connection object is not required because autostarted domains are
never marked for autodestroy.
The comment about needing a connection for the network driver is
obsolete since we can auto-open a connection on demand.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This allows for passinga NULL connection object in cases where
domain autodestroy is not required.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
On incoming migration qemu doesn't activate the block graph nodes right
away. This is to properly facilitate locking of the images.
The block nodes are normally re-activated when starting the CPUs after
migration, but in cases (e.g. when a paused VM was migrated) when the VM
is left paused the block nodes are not re-activated by qemu.
This means that blockjobs which would want to write to an existing
backing chain member would fail. Generally read-only jobs would succeed
with older qemu's but this was not intended.
Instead with new qemu you'll always get an error if attempting to access
a inactive node:
error: internal error: unable to execute QEMU command 'blockdev-mirror': Inactive 'libvirt-1-storage' can't be a backing child of active '#block052'
This is the case for explicit blockjobs (virsh blockcopy) but also for
non shared-storage migration (virsh migrate --copy-storage-all).
Since qemu now provides 'blockdev-set-active' QMP command which can
on-demand re-activate the nodes we can re-activate them in similar cases
as when we'd be starting vCPUs if the VM weren't left paused.
The only exception is on the source in case of a failed post-copy
migration as the VM already ran on destination so it won't ever run on
the source even when recovered.
Resolves: https://issues.redhat.com/browse/RHEL-78398
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The command will be used to re-activate block nodes after migration when
we're leaving the VM paused so that blockjobs can be used.
As the 'node-name' field is optional the 'qemumonitorjsontest' case
tests both variants.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The flag signals presence of the 'blockdev-set-active' QMP command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Notable changes:
- 'blockdev-set-active' QMP command and the corresponding 'active'
flag for instantiating blockdev backends added
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The query language allows querying whether a member is optional by using
the '*' "operator" but the dumper script didn't output those query
strings.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
'qemuDomainSupportsCheckpointsBlockjobs()' should really be used only
with active VMs based on the scope of interlocking it does.
This means that the inactive snapshot code path needs to do the
interlocking based on what's supported:
- external snapshot support was not implemented yet
(bitmaps need to be propagated to the new overlay image)
- internal snapshot support can be deferred to qemu
Move the check inside qemuSnapshotPrepare() which has knowledge about
the snapshot type and implement an explicit check for the inactive case.
See: https://gitlab.com/libvirt/libvirt/-/issues/739
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The commit in question made an incorrect change that resulted in getting
O_RDONLY FD instead of O_RDWR preventing any writes to happen with the
following error:
virQEMUSaveDataWrite:176 : failed to write header to domain save file '/path/to/save.img': Bad file descriptor
Pass 'bypass_cache' as proper bool as the original code did.
Fixes: 517248e239
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This replaces Fedora 39 with Fedora 41, updates the FreeBSD
Cirrus CI image names, and tweaks some package names
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When processing the PCI devices we can only read the configs for each of
them if running as privileged. That information is saved in the driver
state as a boolean introduced in commit 643c74abff. However since
that version it is only written to once during nodeStateInitialize() and
only read from that point (apart from some commits around v3.9.0 release
when it was not even set, but that was fixed before v3.10.0). And it is
only read once, just to store that boolean in a temporary variable which
is also used in only one condition.
Rewrite this without locking and save few lines of code.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add reporting an internal error when the string to type conversion of
devtype fails as this indicates a serious problem since devtype was used
to get into this method during the udev event handling.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The call to 'qemuBlockStorageSourceNeedsFormatLayer()' bases the
decision also on the state of the passed FD, so we must initialize the
passthrough data via 'qemuDomainPrepareStorageSourceFDs()' before the
aforementioned call.
In the test change it's visible that we didn't add the necessary 'raw'
driver which allows the 'protocol' blockdev to be opened in 'rw' mode so
that qemu picks the proper file descriptior while keeping the device
read-only.
Resolves: https://issues.redhat.com/browse/RHEL-37519
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add few examples of fd groups with the 'writable' flag set, when passing
a single FD. Notably as a top level image of a readonly disk (even when
that doesn't make much sense) and also as a base image of a chain.
Note that this documents a status quo of a bug fixed in upcoming patch.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Pass also the 'writable' state to the fake passed FDs so that we can
test it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Recently, I was part of a discussion where it was suspected that
libvirt does not pick up correct FW for SEV-SNP guests. Update
our test to demonstrate it does.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Similarly to commit 1af45804 we should be safer by waiting for the whole
sysfs tree is created for the device.
Signed-off-by: Guoyi Tu <tugy@chinatelecom.cn>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Check if the persistent reservations manager daemon is still needed
after a disk (sub)-chain was dropped after a blockjob.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Export qemuHotplugAttachManagedPR/qemuHotplugRemoveManagedPR for reuse
in blockjob code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Consider also the destination of a block-copy job.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add data based on 'v9.2.0-1537-gd922088eb4'
Notable changes:
- '10.0' machine types added
- 'hub' chardev backend added
- 'cpr' migrate channel added
- 'nsamples' field for 'dbus' audio backend now reported
- 'ClearwaterForest-v1' cpu model added
- 'SierraForest-v2' cpu model added
- 'ivshmem-flat' device added
- new qom objects:
- 'virtio-mem-system-reset'
- 'vmclock'
- default value of 'rombar' changed from 1 to -1 for all devices
- 'intel-iommu' device:
- default value of 'aw-bit' changed from '39' to '48'
- 'fs1gp' boolean added
- 'x-flts' boolean added
- 'virtio-balloon-pci'/'virtio-mem-pci':
- 'ioeventfd' added
- 'vectors' added
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update the data after the release.
Notable changes:
- the 6.2 machine types became deprecated
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Attempting to take an internal snapshot of a freshly defined VM with
qcow2 backed NVRAM results in failure as the NVRAM image doesn't get
populated until the VM is started for the first time.
Fix this by invoking qemuPrepareNVRAM() when qcow2 nvram is defined.
Resolves: https://issues.redhat.com/browse/RHEL-73315
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Export qemuPrepareNVRAM so that it doesn't require the VM object. The
snapshot code needs in the corner case of creating a snapshot of a
freshly defined VM ensure that the nvram image exists in order to
snapshot it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The variable holds the amount of disks to roll back the snapshot for.
The value must be set before the code jumps to the 'rollback:' label so
the best situation is to not initialize it and let the compiler catch
errors rather than initialize the unsigned variable to -1 and let it
crash.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
clang complains:
../../../libvirt/src/node_device/node_device_udev.c:1408:82: error: result of comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-unsigned-enum-zero-compare]
1408 | if ((data->ccwgroup_dev.type = virNodeDevCCWGroupCapTypeFromString(devtype)) < 0)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
1 error generated.
Fix it by adding a temporary int variable to facilitate the check before
assigning to the unsigned enum value.
Fixes: 985cb9c32a
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add the group membership information to a CCW device. Allow to filter
CCW devices based on a group membership.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The fields are in nanoseconds, not microseconds. Also fixes the
description of `vcpu.<num>.wait`, as it does not actually represent the
time waiting on I/O.
Signed-off-by: Fabricio Duarte <fabricio.duarte.jr@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In case when the hypervisor does report the reason for the I/O error as
an unstable string to display to users we can add a @reason possibility
for the I/O error event noting that the error is available.
Add 'message' as a reason enumeration value and document it
to instruct users to look at the logs or virDomainGetMessages().
The resulting event looks like:
event 'io-error' for domain 'cd': /dev/mapper/errdev0 (virtio-disk0) report due to message
Users then can look at the virDomainGetMessages() API:
I/O error: disk='vda', index='1', path='/dev/mapper/errdev0', timestamp='2025-01-28 15:47:52.776+0000', message='Input/output error'
Or in the VM log file:
2025-01-28 15:47:52.776+0000: IO error device='virtio-disk0' node-name='libvirt-1-storage' reason='Input/output error'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Emphasise that it's an enumeration and convert the possibilities to a
list of values with explanation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Report any stored I/O error messages reported by the hypervisor when
reporting messages of a domain. As the I/O error may be already stale we
report also the timestamp when it was recorded.
Example message:
I/O error: disk='vda', index='1', path='/dev/mapper/errdev0', timestamp='2025-01-28 15:47:52.776+0000', message='Input/output error'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Simplify the function especially by rewriting it using GPtrArray to
construct the string list, especially for the upcoming case when the
number of added elements will not be known beforehand and when
hypervisor specific data will be added.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The two VIR_DOMAIN_MESSAGE_* flags were not listed in the virCheckFlags
check in 'libxl' but were present in 'test' and 'qemu' driver impls.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add a log entry to the VM log file for every time we receive an IO error
event from qemu. The log entry is as follows:
2025-01-24 16:03:28.928+0000: IO error device='virtio-disk0' node-name='libvirt-1-storage' reason='other: Input/output error'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Record the last I/O error reason and timestamp which happened with the
corresponding virStorageSource struct.
This will later allow querying the last error e.g. via the
virDomainGetMessages() API.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Hypervisors may report a I/O error message (unstable; for human use)
to libvirt. In order to store it with the appropriate virStorageSource
so that it can be later queried we need to add fields to
virStorageSource to store the timestamp and message.
The message is deliberately not copied via virStorageSourceCopy.
The messages are also not serialized to the status XML as losing them on
a daemon restart as they're likely to be stale anyways.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU commit v9.1.0-1065-ge67b7aef7c added 'qom-path' as an optional
field for the BLOCK_IO_ERROR event. Extract and propagate it as an
alternative to lookup via 'node-name' and 'device' (alias).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When qemu reports a node name for an I/O error we should prefer the
lookup by node name instead as it gives us the path to the specific
image which caused the error instead of the top level image path.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Leave the interpretation of the event to 'qemuProcessHandleIOError()'
which will create it's own variant of the messages for the user-facing
libvirt events. qemuMonitorJSONHandleIOError() will pass through the raw
data it got from qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Prefix the helper variables used to supply data to the event by
'event'. Declare them with the default value of an empty string rather
than doing it later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The field is named 'device' in the event so unify our naming.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
BLOCK_IO_ERROR's 'device' field is an empty string in case when it isn't
applicable as it was originally mandatory in the qemu API docs.
Move the logic that convert's empty string back to NULL from
'qemuProcessHandleIOError()' to 'qemuMonitorJSONHandleIOError()'
This also fixes a hypothetical NULL-dereference if qemu would indeed
report an IO error without the 'device' field present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This is similar to emuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
except the explicit placement of virtio-mem onto a PCI bus is removed.
This results in virtio-mem being placed onto CCW "bus" this demonstrating
previous commits working as expected.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
After previous commits, we can allow virtio-mem to live on CCW
channel.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
There are basically two differences between virtio-mem-ccw and
virtio-mem-pci. s390 doesn't allow mixing different page sizes
and there's no NUMA support in QEMU.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
This capability tracks whether QEMU supports virtio-mem-ccw
device. Introduced in QEMU commit v9.2.0-492-gaa910c20ec only
upcoming release of QEMU supports the device.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
As of v9.2.0-1413-gd77ae821e8 QEMU supports virtio-mem-pci on
s390 too. Let's add a test case for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Both, virtio-mem and virtio-pmem devices follow traditional QEMU
naming convention: their suffix determines what bus they live on.
For instance, virtio-mem-pci, virtio-mem-ccw, virtio-pmem-pci.
We already have a function that constructs device name following
this convention: qemuBuildVirtioDevGetConfigDev().
While there's no virtio-pmem-ccw device yet, the function can
still be used.
Another advantage of using the function is - it'll be easier in
future when we want to configure various virtio aspects of memory
devices (like ats, iommu_platform, etc.).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
In some cases, we might automatically add a NUMA node. But this
doesn't work for s390 really, because in its commit
v2.12.0-rc0~41^2~6 QEMU forbade specifying NUMA nodes for s390.
Suppress automatic adding of NUMA node on our side.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
In Fedora >= 42, support for user/group account creation based on
sysusers files has been enabled in RPM. Manually running useradd/
groupadd is thus obsolete.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We previously added a sysusers file, but missed the 'virtlogin' group.
This group is used to make the virt-login-shell binary setgid, so we
shoudl be registering that too. It must be done in a separate sysusers
file, however, since it is packaged separately from the daemons.
Fixes: a2c3e390f7
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that only supported version of VirtualBox is 7.0.x the code
that supports older versions can be dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
If initialization of VBOX fails inside of _pfnInitialize an
negative value is returned to signal an error condition to a
caller but no error message is printed out. Reporting an error
may shed more light into why VBOX failed to initialize.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When attempting to restore a saved image, the check for a valid save image
format does not occur until the qemu process is about to be executed. Move
the check earlier in the restore process, along with the other checks that
verify a valid save image header.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Split the reading of libvirt's save image metadata from the opening
of the fd that will be passed to QEMU. This allows improved error
handling and provides more flexibility users of qemu_saveimage.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemuDomainObjRestore is the only caller of qemuSaveImageOpen that
requests an unlink of a corrupted save image. Provide a function to
check for a corrupt image and move unlinking it to qemuDomainObjRestore.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We previously added a sysusers file, but missed the 'libvirt' group.
This group is referenced in the polkit rules, so we should be
registering that too. It must be done in a separate sysusers file,
however, since it is common to all daemons.
Fixes: a2c3e390f7
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Ever since its introduction, g_string_replace() has received
various bugfies and improvements, e.g.:
0a8c7e57a g_string_replace: Don't replace empty string more than once per location
b13777841 g_string_replace: Document behaviour of zero-length match pattern
e8517e777 remove quadratic behavior in g_string_replace
c9e48947e gstring: Fix a heap buffer overflow in the new g_string_replace() code
to name a few. Sync our implementation with the one from current
main branch of glib. Some code style adjustments have been made
to match our coding style.
Signed-off-by: Adam Julis <ajulis@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemuDomainDiskByName() can return a NULL pointer on failure.
But this returned value in qemuSnapshotDeleteValidate is not checked.It will make libvirtd crash.
Signed-off-by: kaihuan <jungleman759@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Provide a proper user facing error when attempting to query block
I/O throttling settings for an empty drive. Without this patch, a less
meaningful internal error produced by qemuMonitorJSONBlockIoThrottleInfo
would be propagated to the user.
Signed-off-by: Fabian Leditzky <fabian@ldsoft.dev>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since we supported 'product' parameter for SCSI, just expanded existing
solution makes IDE/SATA parameter works too. QEMU requires parameter 'model'
in case of IDE/SATA (instead of 'product'), so the process of making JSON
object is slightly modified. Length of the 'product' parameter is
different in SCSI (16 chars) and ATA/SATA (40 chars).
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/697
Signed-off-by: Adam Julis <ajulis@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When snapshot is created with disk-only flag it is always external
snapshot without memory state. Historically when there was not support
to revert external snapshots this produced error message.
error: Failed to revert snapshot s1
error: internal error: Invalid target domain state 'disk-snapshot'. Refusing snapshot reversion
Now we can simply consider this as reverting to offline snapshot as the
possible damage to file system is already done at the point of snapshot
creation.
Resolves: https://issues.redhat.com/browse/RHEL-21549
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This directory might not exist on systems not supporting old SystemV interfaces.
Signed-off-by: Bronek Kozicki <brok@incorrekt.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
By removing the unnecessary spaces, the behavior is aligned with
`virsh list --all --name` and `virsh net-list --all --name`.
Without this change, one can't do something like the following easily:
`virsh pool-list --all --name | xargs -I {} virsh pool-start \"{}\"`
as no pool `"foo "` (with all the spaces) actually exist.
Although the removed comment states that the additional spaces were kept
to maintain backwards compatibility, the commit [0] and the old behavior
are from 2010 when libvirt was at version 0.8.1. For the sake of sanity,
the behavior should be aligned with other parts of the CLI.
[0] 415b14903e
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The VM private data will be used in a sub-sequent patch. To minimize
churn, refactor the function before changing the logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Per our supported platforms the minimum available versions are:
CentOS Stream 9: 2.68.4
Debian 11: 2.66.8
Fedora 39: 2.78.6
openSUSE Leap 15.6: 2.78.6
Ubuntu 22.04: 2.72.4
FreeBSD ports: 2.80.5
macOS homebrew: 2.82.4
macOS macports: 2.78.4
Bump to 2.66 which is limited by Debian 11. While ideally we'd bump to
2.68 which would give us 'g_strv_builder' and friends 2.66 is enough for
g_ptr_array_steal() which can be used to emulate the former with almost
no extra code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since the empty file with a .base64 value wasn't recognized during the loading
process (starting of libvirtd), attempting to get a value for the UUID resulted
in an undefined error. This patch resolves the issue by checking the size of
the file and ensuring that the stored value is as expected (NULL).
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Adam Julis <ajulis@redhat.com>
There's a call to read() in the file but corresponding include of
unistd.h is missing causing a build failure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When a migration with non-shared storage is started with
VIR_MIGRATE_PARAM_BANDWIDTH set, it will be applied to both memory
migration and each block job started for storage migration. Once the
migration is running virDomainMigrateSetMaxSpeed may be used to change
the bandwidth used by memory migration, but there was no way of changing
storage migration speed. Let's allow virDomainBlockJobSetSpeed during
migration to enable the missing functionality.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The new VIR_MIGRATE_PARAM_BANDWIDTH_AVAIL_SWITCHOVER parameter can be
used to override the estimated bandwidth that can be used for
transferring guest memory and device state once virtual CPUs are
stopped.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that meson ensures these directories always exist, we can
move them to the daemon-common package where they belong.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
All loadable modules should depend on the daemon-common package.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently the directories that are searched for each possible
kind of loadable module are created as a side effect of
installing the corresponding module, which means that their
availability depends on the exact list of features that have
been enabled.
Create them explicitly ahead of time instead, ensuring
consistency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement domainInterfaceAddresses for the Cloud Hypervisor driver.
Support VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_LEASE and
VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP sources. Implementation is
similar to other drivers.
Signed-off-by: Anirudh Rayabharam <anrayabh@linux.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>
Implement `virCHProcessEvent` that maps event string to corresponding
event type and take appropriate actions. As part of this, handle the
shutdown event by correctly updating the domain state. This change also
facilitates the handling of other VM lifecycle events, such as booting,
rebooting, pause, resume, etc.
Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use a FIFO(named pipe) for --event-monitor option in CH. Introduce a new
thread, `virCHEventHandlerLoop`, to continuously monitor and handle
events from cloud-hypervisor.
Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
Co-authored-by: Vineeth Pillai <viremana@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The `--event-monitor` option in cloud-hypervisor outputs events to a
specified file. This file can then be used to monitor VM lifecycle,
other vmm events and trigger appropriate actions.
Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi@linux.microsoft.com>
Co-authored-by: Vineeth Pillai <viremana@linux.microsoft.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Most of my historical libvirt contributions are PowerPC related but at
this moment I'm working with RISC-V enablement (mostly on the QEMU
side).
Feel free to reach out for RISC-V related matters w.r.t libvirt and
QEMU-KVM support.
Suggested-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The 'aia' feature is added as a machine type option for the 'virt'
RISC-V machine, e.g. "-machine virt,aia=<val>".
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This feature is implemented as a string that can range from "none",
"aplic" and "aplic-imsic".
If the feature isn't present in the domain XML the hypervisor default
will be used. For QEMU, at least up to 9.2, the default is "none".
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
AIA (Advanced Interrupt Architecture) support was introduced in QEMU 7.0
for the 'virt' machine type. It allows the guest to choose from a more
modern interrupt model than the default (CLINT - Core Logical Interrupt
Controller).
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The correct compiler define to detect the RISC-V architecture is __riscv.
Fixes: b902cfece0 ("virsysinfo: Try reading DMI table")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Let us introduce the xml and reply files for QEMU 10.0.0 on s390x.
Notable changes:
- new s390-ccw-virtio-10.0 machine type
- old machine types (2.4 - 2.8) dropped
- new CPU models
- New devices:
- virtio-mem-ccw
- chardev now supports qemu-vdagent
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Suggested-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When a migration is canceled very late once virtual CPUs are already
stopped, QEMU will automatically resume them. If this happens after we
exited a waiting loop in qemuMigrationSrcWaitForCompletion, but before a
loop that tries to make sure CPUs are stopped by waiting for the
appropriate event, we may end up waiting forever because the CPUs are
running (they were resumed by migrate_cancel), but the STOP event is
already gone.
This is possible because we enter monitor for fetching migration
statistics at which point other APIs can be processed and migration may
change its state. We should recheck the state when we get back from the
monitor code.
https://issues.redhat.com/browse/RHEL-52493
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Inactive domain XML can be wildly different to the live XML. For
instance, it can have VSOCK CID of that from another (running)
domain. Since domain status is not checked for, attempting to ssh
into an inactive domain may in fact result in opening a
connection to a different live domain that listens on said CID
currently.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/737
Resolves: https://issues.redhat.com/browse/RHEL-75577
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
JSON parser isn't called when reading empty files so `jerr` will be used
uninitialized in the original code. Empty files appear when a network
has no dhcp clients.
This patch checks for such files and skip them.
Fixes: a8d828c88b
Signed-off-by: Jiang XueQian <jiangxueqian@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This matches the cpu_family() check in `meson.build`
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit f8558a87ac de-modularized the
'storage-file' backend for local files, and thus now the only
possibility to have the directory is when compiling with gluster.
This breaks RPM builds when building without gluster as the backend
directory no longer exists in such case. Move the stanza requiring the
directory under the gluster driver declarations.
Fixes: f8558a87ac
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In its upstream commit [1], qemu dropped s390-2.7 machine type,
then in commit [2] the s390-2.8 machine type was dropped. But as
Thomas Huth pointed out, any machine type that's older than 6
years is subject to removal [3]. This means, any machine type
older than 4.1 is going to be removed eventually.
We have two test cases that assumes existence of 2.7 machine type.
While they could be switched to 4.1 machine type, we also have
another test case that already check 4.2 machine type.
Therefore, just drop the 2.7 ones.
1: 3199c7ee76
2: 66924fe369
3: ce80c4fa6f
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
The 'storage_file' infrastructure serves as an abstraction on top of
file-looking storage technologies. Apart from local file it currently
implements also a backend for 'gluster'.
Historically it was all modularized and the local file module was
usually packaged with the 'core' part of the storage driver. Now with
split daemons one can install e.g. 'virqemud' without the storage driver
core which contains the 'fs' backend module. Since the qemu driver uses
the storage file backends to e.g. create storage for snapshots and
backups this allows users to create a deployment where some things will
not work properly.
As the 'fs' backend doesn't use any code that wouldn't be linked
directly anyways there's no point in actually shipping it as a module.
Let's compile it in so that all deployments can use it.
To achieve that, compile the source directly into the
'virt_storage_file_lib' static library and remove the loading code. Also
adjust the spec file.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an example image formatted by:
qemu-img create -f qcow2 -o data_file=nbd+unix:///datafile?socket=/tmp/nbd,data_file_raw=true /tmp/nbddatastore.qcow2 10M -u
serving as an example when qemu records an empty string as the
'data_file' field.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In certain buggy conditions qemu can create an image which has empty
string stored as 'data_file'. While probing libvirt would consider the
empty string as a relative file name and construct the path using the
path of the parent image stripping the last component and appending the
empty string. This results into attempting to using a directory as an
image and thus the following error when attempting to start VM with such
an image:
error: unsupported configuration: storage type 'dir' requires use of storage format 'fat'
Reject empty strings passed in as 'data_file'.
Note that we do not have the same problem with 'backing store' as an
empty string there is interpreted as no backing file both by qemu and
libvirt.
Resolves: https://issues.redhat.com/browse/RHEL-70627
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The assigned string is 17 chars long once the trailing nul is taken
into account. This triggers a warning with GCC 15
src/util/virsystemd.c: In function ‘virSystemdEscapeName’:
src/util/virsystemd.c:59:38: error: initializer-string for array of ‘char’ is too long [-Werror=unterminated-string-initialization]
59 | static const char hextable[16] = "0123456789abcdef";
| ^~~~~~~~~~~~~~~~~~
Switch to a dynamically sized array as used in all the other places
we have a hextable array.
See also: https://gcc.gnu.org/PR115185
Reported-by: Yaakov Selkowitz <yselkowi@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The list of CPU features we probe from various MSR grew significantly
over time and the CPU map currently mentions 11 distinct MSR indexes.
But the code for directly probing host CPU features was still reading
only the original 0x10a index. Thus the CPU model in host capabilities
was missing a lot of features.
Instead of specifying a static list of indexes to read (which we would
forget to update in the future), let's just read all indexes found in
the CPU map.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When an I/O error happens (causing a domain to be paused) during live
migration which is later cancelled by a user, trying to resume the
domain doesn't make sense.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
None of the callers really care about the return value so we can drop it
and simplify the code a bit.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When migration fails in Perform phase, we call Finish on the destination
host with cancelled=1 and get the error from there and report it to the
user. This works well if the error on the destination caused the
migration to fail. But in other cases the main error may reported by the
source and the destination would just be complaining about broken
migration stream.
In other words, we don't really know which error caused the migration to
fail and we have no way of detecting that. So instead of choosing one
error, this patch will combine the error messages from both sides of
migration into a single message and report it to the user. The result
would be, for example:
operation failed: migration failed. Message from the source host:
operation failed: job 'migration out' failed: Certificate does not
match the hostname ble.bla. Message from the destination host:
operation failed: job 'migration in' failed: load of migration
failed: Invalid argument
And yes, this is ugly, but I wasn't able to come up with a better way of
fixing this issue.
https://issues.redhat.com/browse/RHEL-58933
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
@ -633,7 +633,7 @@ analysis tools understand the code better:
``G_GNUC_FALLTHROUGH``
allow code reuse by multiple switch cases
``G_NO_INLINE``
``ATTRIBUTE_MOCKABLE``
the function is mocked in the test suite
``G_GNUC_NORETURN``
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.