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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Trying to disable <seclabel> for the whole <domain> and _also_
disable <seclabel> at the <disk> level will fail with:
error: unsupported configuration: label overrides require relabeling to be enabled at the domain level
which seems wrong. Instead skip the validation when disk seclabel
has relabel='no', that config should always be valid.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Update default to 0xFFFFFFFF ("never notify" in qemu) and make retries
attribute optional.
Signed-off-by: Friedrich Oslage <friedrich@oslage.de>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
So far we have two modes for hyperv features:
1) custom, where users have to enable features explicitly, and
2) passthrough, where hypervisor enables features automagically.
Problem with 'custom' mode is that some features are not plain
on/off switches but expect int/string value. Until very recently,
these were not reported in domcaps. And even if they were it's a
bit cumbersome.
Problem with 'passthrough' mode is that users don't get to see
the expanded list of enlightenments enabled.
Therefore, mimic what we're already doing with CPUs: have
'host-model' which gets expanded at domain startup and is fixed
throughout domain's run.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is another case where the current behavior can be traced
back to the fact that x86 was the only architecture to really
be taken into account for a long time: in reality, using an
Intel-specific USB1 controller for a modern, PCIe-native,
virtualization-friendly Arm guest just doesn't make any sense.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have special behavior for these two machine types, and
more specifically for the USB controller that they get added
by default - something that doesn't generally happen on Arm.
Not only this is inconsistent with other machine types for
the architecture, it also means that the model for the USB
controller that gets added automatically (pci-ohci, USB1) is
worse than the default one for user-added USB controllers
(qemu-xhci, USB3) which is just silly.
Bring these machine types in line with the rest of the
architecture.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently we differentiate between 64-bit and 32-bit
architectures, which doesn't seem very reasonable
considering that the same machine types are available
in both cases. Remove this inconsistency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similar to loongarch64, the current behavior is a result
of the way the existing code was written rather than a
consequence of an intentional choice. Make the two
architectures behave the same way, as they should have
from the start.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The architecture was introduced at a time when USB3 in
general, and qemu-xhci in particular, had already been
well established for years. Having USB1 controllers as a
fallback was something that happened by mistake due to
the way the pre-existing code was organized rather than
because of a conscious decision. Make things work the
way they should have in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Right now we call qemuValidateDomainDeviceDefControllerUSB()
quite late, just as we're generating the QEMU command line.
The original intention was likely to prevent configurations
from being rejected, even though a default USB controller
model could not be found, because using -usb could be used
as a last resort.
As it turns out, this premise was always flawed: in order
for -usb to work, the underlying device still needs to be
compiled into QEMU, and if that was the case then the
earlier code would have detected its presence and set the
model name accordingly.
More recently, we have dropped the use of -usb altogether
so there's simply no longer anything to fall back to.
With all this in mind, we can move the validation step much
earlier, making for a better user experience as any issues
will be reported when the domain is defined rather than when
an attempt is made to start it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The sparc architecture doesn't support PCI, and neither do the
isapc and microvm machine types on x86 architectures.
One of the isapc/microvm tests starts failing as a consequence
of this change, which is expected; somewhat surprisingly,
another test for the same machine types goes from an early/hard
failure (PARSE_ERROR) to a late/soft one (FAILURE) instead.
This will be rectified by a later commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At the moment, we check whether the machine type supports PCI
before attempting to allocate PCI addresses, and if it does
not, we simply skip the step entirely.
This means that an attempt to use a PCI device with a machine
type that has no PCI support won't be rejected by libvirt, and
only once the QEMU process is started the problem will be made
apparent.
Validate things ahead of time instead, rejecting any such
configurations.
Note that we only do this for new domains, because otherwise
existing domains that are configured incorrectly would disappear
and we generally try really hard to avoid that.
A few tests start failing after this change, demonstrating that
things are now working as desired.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The microvm machine type doesn't support PCI, so adding PCI
controllers to it doesn't make sense, nor does adding a
USB controller or a memballon since both are PCI devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Neither machine type supports PCI, so attempting to add a
PCI controller should fail. It currently doesn't, and we're
going to address that in an upcoming commit.
Note that the domain gets a PCI memballoon device added
automatically. That also shouldn't happen, and will similarly
be fixed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These tests are intended to show what happens when the device
that libvirt would use by default is not available in QEMU by
dropping the corresponding capabilities, but we're not doing
that correctly at the moment and so we still get the default
USB controller instead of a failure.
Specifically, we should be dropping all capabilities related
to devices that might be used as default or automatic USB
controllers for the machine type so that libvirt will report
an error, but for these few tests we are currently only
listing a subset of the capabilities that we should be
dropping.
Note that the usb-controller-automatic-unavailable tests are
still behaving the same despite dropping all the expected
capabilities: the reason is that, for that scenario, we're
not currently checking whether the device is available before
using it. That's a separate issue that will be addressed in an
upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We're missing a significant number of scenarios, including
those involving fairly common machine types and architectures.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To usb-controller-automatic-*.
This matches the existing q35 test, and in general makes more
sense as a name since these tests are providing coverage for
USB controllers getting automatically added by libvirt for new
domains, rather than implicit (i.e. built-in, non-removable)
devices.
Note that, in the case of physical i440fx machines, the USB
controller is actually part of the chipset and would thus
qualify as implicit; the corresponding QEMU machine type,
however, allows for it to be removed, so the new name is still
more appropriate when discussing virtual hardware.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We already test the machine type on armv7l and realview on
aarch64, so these handful of test cases can be dropped without
negatively impacting our coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The USB vendor/product is usually translated into a device/bus at
startup using the hostdev logic. We don't run the latter in the
unit test suite, but we can fake it by hardcoding a translation.
This demonstrates that we format the command line with the normal
device/bus properties, even when vendor/product is set.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Fake the capabilities based on the QEMU version so that we can test
the command line for both the C version of virtiofsd (removed in QEMU
8.0.0) and the Rust version.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Introduce testing of the generated command line arguments
of helper binaries too, not just QEMU.
Start with passt.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Next patch will need this to construct the path to the output
file in a deeper level of nesting.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The current code assumes that a stateless firmware has to be
explicitly requested by the user, and should never be picked
otherwise. This means that, for example, domains configured to
use SEV-SNP are forced to explicitly request for the firmware
to be stateless.
Additionally, we assume that only split firmware is suitable
for the stateful use case, whereas a combined firmware image
would also do the job.
As a result of these changes, the failing SEV-SNP test case
that was added recently passes, and so do the test cases
requesting read/write firmware.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
One of the new test cases demonstrates how firmware
autoselection doesn't currently work correctly for domains
using SEV-SNP: the descriptor for a suitable firmware exists,
and yet it doesn't get picked up.
Another test cases shows that, while firmware autoselection
succeeds for non-SNP SEV domains, the results are not the
expected ones: the generic (stateful) edk2 build is used
instead of the SEV-specific (stateless) one. This will be
addressed in a future patch by updating the descriptors.
Finally, one test case provides coverage for the uncommon
scenario of stateful firmware being explicitly requested by
the user.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Now that the qemu capabilities dump for the qemu-10.2 cycle was added
and thus qemu-10.1 dump is no longer "latest" we can pin the
'cpu-host-' tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu-10.2 which we're about to add capabilities dump for will remove the
'4.2' machine type per deprecation policy.
The 'x86_64-default-cpu-*' still reference it. Since there is no
functional difference when upgrading the tests to the latest machine
type (pc/q35 alias as handled internally by qemuxmlconftest) let's
rename and modernize these.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@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>
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>
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>
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>
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>
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>
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>
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>
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 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>
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>
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>
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>
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>
