Michal Privoznik [Tue, 22 Aug 2023 07:45:47 +0000 (09:45 +0200)]
src: Detect close_range syscall during virGlobalInit()
The whole purpose of virCloseRangeInit() is to be called
somewhere during initialization (ideally before first virExec()
or virCommandRun()), so that the rest of the code already knows
kernel capabilities. While I can put the call somewhere into
remote_daemon.c (when a daemon initializes), we might call
virCommand*() even from client library (i.e. no daemon).
Therefore, put it into virGlobalInit() with the rest of
initialization code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Michal Privoznik [Tue, 22 Aug 2023 07:41:32 +0000 (09:41 +0200)]
vircommand: Introduce virCommandMassCloseRange()
This is brand new way of closing FDs before exec(). We need to
close all FDs except those we want to explicitly pass to avoid
leaking FDs into the child. Historically, we've done this by
either iterating over all opened FDs and closing them one by one
(or preserving them), or by iterating over an FD interval [2 ...
N] and closing them one by one followed by calling closefrom(N +
1). This is a lot of syscalls.
That's why Linux kernel developers introduced new close_from
syscall. It closes all FDs within given range, in a single
syscall. Since we keep list of FDs we want to preserve and pass
to the child process, we can use this syscall to close all FDs
in between. We don't even need to care about opened FDs.
Of course, we have to check whether the syscall is available and
fall back to the old implementation if it isn't.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Michal Privoznik [Mon, 21 Aug 2023 13:10:39 +0000 (15:10 +0200)]
vircommand: Unify mass FD closing
We have two version of mass FD closing: one for FreeBSD (because
it has closefrom()) and the other for everything else. But now
that we have closefrom() wrapper even for Linux, we can unify
these two.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Michal Privoznik [Mon, 21 Aug 2023 13:10:25 +0000 (15:10 +0200)]
virfile: Introduce virCloseFrom()
It is handy to close all FDs from given FD to infinity. On
FreeBSD the libc even has a function for that: closefrom(). It
was ported to glibc too, but not musl. At least glibc
implementation falls back to calling:
close_range(from, ~0U, 0);
Now that we have a wrapper for close_range() we implement
closefrom() trivially.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Michal Privoznik [Tue, 22 Aug 2023 06:49:10 +0000 (08:49 +0200)]
virfile: Introduce virCloseRange()
Linux gained new close_range() syscall (in v5.9) that allows
closing a range of FDs in a single syscall. Ideally, we would use
it to close FDs when spawning a process (e.g. via virCommand
module).
Glibc has close_range() wrapper over the syscall, which falls
back to iterative closing of all FDs inside the range if running
under older kernel. We don't wane that as in that case we might
just close opened FDs (see Linux version of
virCommandMassClose()). And musl doesn't have close_range() at
all. Therefore, call syscall directly.
Now, mass close of FDs happens in a fork()-ed off child. While it
could detect whether the kernel does support close_range(), it
has no way of passing this info back to the parent and thus each
child would need to query it again and again.
Since this can't change while we are running we can cache the
information - hence virCloseRangeInit().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Michal Privoznik [Thu, 17 Aug 2023 12:52:12 +0000 (14:52 +0200)]
src: Rename some members of _virDomainMemoryDef struct
As advertised earlier, now that the _virDomainMemoryDef struct is
cleaned up, we can shorten some names as their placement within
unions define their use.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Fri, 28 Jul 2023 09:40:37 +0000 (11:40 +0200)]
src: Move _virDomainMemoryDef target nodes into an union
The _virDomainMemoryDef struct is getting a bit messy. It has
various members and only some of them are valid for given model.
Worse, some are re-used for different models. We tried to make
this more bearable by putting a comment next to each member
describing what models the member is valid for, but that gets
messy too.
Therefore, do what we do elsewhere: introduce an union of structs
and move individual members into their respective groups.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 25 Jul 2023 14:48:21 +0000 (16:48 +0200)]
src: Move _virDomainMemoryDef source nodes into an union
The _virDomainMemoryDef struct is getting a bit messy. It has
various members and only some of them are valid for given model.
Worse, some are re-used for different models. We tried to make
this more bearable by putting a comment next to each member
describing what models the member is valid for, but that gets
messy too.
Therefore, do what we do elsewhere: introduce an union of structs
and move individual members into their respective groups.
This allows us to shorten some names (e.g. nvdimmPath or
sourceNodes) as their purpose is obvious due to their placement.
But to make this commit as small as possible, that'll be
addressed later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_driver: validate mem->model on MEMORY_DEVICE_SIZE_CHANGE event
When guest acknowledges change in size of virtio-mem (portion
that's exposed to the guest), QEMU emits
MEMORY_DEVICE_SIZE_CHANGE event. We process it in
processMemoryDeviceSizeChange(). So far, QEMU emits the even only
for virtio-mem (as that's the only memory device model that
allows live changes to its size). Nevertheless, if this ever
changes, validate the memory model upon processing the event as
the rest of the code blindly expects virtio-mem model.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Fri, 28 Jul 2023 12:39:31 +0000 (14:39 +0200)]
conf: Compare memory device address in virDomainMemoryFindByDefInternal()
This is similar to one of my previous commits. Simply speaking,
users can specify address where a memory device is mapped to. And
as such, we should include it when looking up corresponding
device in domain definition (e.g. on device hot unplug).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 27 Jul 2023 13:14:12 +0000 (15:14 +0200)]
qemu_hotplug: Don't validate inaccessible fields in qemuDomainChangeMemoryLiveValidateChange()
The qemuDomainChangeMemoryLiveValidateChange() function is called
when a live memory device change is requested (via
virDomainUpdateDeviceFlags()). Currently, the only model that is
allowed to change is VIRTIO_MEM (and the only value that's
allowed to change is requestedsize). The aim of the function is
to check whether the change user requested follows this rule. And
in accordance with defensive programming I made the function
check all virDomainMemoryDef struct members. Even those which are
unused for VIRTIO_MEM model.
Drop these checks as the respective members will be inaccessible
soon (as the struct is refined).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_hotplug: validate address on memory device change
As of v7.9.0-rc1~296 users have ability to adjust what portion of
virtio-mem is exposed to the guest. Then, as of v9.4.0-rc2~5 they
have ability to set address where the memory is mapped. But due
to a missing check it was possible to feed
virDomainUpdateDeviceFlags() API with memory device XML that
changes the address. This is of course not possible and should be
forbidden. Add the missing check.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 26 Jul 2023 10:36:08 +0000 (12:36 +0200)]
virt-aa-helper: Set label on VIRTIO_PMEM device too
Conceptually, from host POV there's no difference between NVDIMM
and VIRTIO_PMEM. Both expose a file to the guest (which is used
as a permanent storage). Other secdriver treat NVDIMM and
VIRTIO_PMEM the same. Thus, modify virt-aa-helper so that is
appends virtio-pmem backing path into the domain profile too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, inside of virt-aa-helper code the domain definition is
parsed and then all def->mems are iterated over and for NVDIMM
models corresponding nvdimmPath is set label on. Conceptually,
this code works (except the label should be set for VIRTIO_PMEM
model too, but that is addressed in the next commit), but it can
be written in more extensible way. Firstly, there's no need to
check whether def->mems[i] is not NULL because we're inside a
for() loop that's counting through def->nmems. Secondly, we can
have a helper variable ('mem') to make the code more readable
(just like we do in other loops). Then, we can use switch() to
allow compiler warn us on new memory model.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
When running libvirt from the build directory with the 'run' script, it
will run as unconfined_t. This can result in unexpected behavior when
selinux is enforcing due to the fact that the selinux policies are
written assuming that libvirt is running with the
system_u:system_r:virtd_t context. This patch adds a new --selinux
option to the run script. When this option is specified, it will launch
the specified binary using the 'runcon' utility to set its selinux
context to the one mentioned above. Since this may require root
privileges, setting the selinux context is not the default behavior and
must be enabled with the command line switch.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Pavel Hrdina [Mon, 6 Mar 2023 11:25:04 +0000 (12:25 +0100)]
qemu_snapshot: add checks for external snapshot deletion
With the introduction of external snapshot revert support we need to
error out in some cases when trying to delete some snapshots.
If users reverts to non-leaf snapshots and would try to delete it after
the revert is done it would not work currently as this operation would
require using block-stream which is not implemented for now as in this
case the snapshot has two children so the disk files have multiple
overlays.
Similarly if user reverts to non-leaf snapshot and would try to delete
snapshot that is non-leaf but not in currently active snapshot chain we
would still need to use block-commit operation. The issue here is that
in order to do that we would have to start new qemu process with
different domain definition than what is currently used by the domain.
If the current domain would be running it would complicate things even
more so this operation is not yet supported.
If user creates new snapshot after reverting to non-leaf snapshot it
creates a new branch. Deleting snapshot with multiple children will
require block-stream which is not implemented for now.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Wed, 7 Jun 2023 11:02:03 +0000 (13:02 +0200)]
qemu_snapshot: update backing store after deleting external snapshot
With introduction of external snapshot revert we will have to update
backing store of qcow images not actively used be QEMU manually.
The need for this patch comes from the fact that we stop and start QEMU
process therefore after revert not all existing snapshots will be known
to that QEMU process due to reverting to non-leaf snapshot or having
multiple branches.
We need to loop over all existing snapshots and check all disks to see
if they happen to have the image we are deleting as backing store and
update them to point to the new image except for images currently used
by the running QEMU process doing the merge operation.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We only need the domain definition from domain object. This will allow
us to use it from snapshot code where we need to pass different domain
definition.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Mon, 22 May 2023 12:32:35 +0000 (14:32 +0200)]
qemu_snapshot: remove revertdisks when creating new snapshot
When user creates a new snapshot after reverting to non-leaf snapshot we
no longer need to store the temporary overlays as they will be part of
the VM XMLs stored in the newly created snapshot.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Wed, 22 Feb 2023 10:43:45 +0000 (11:43 +0100)]
qemu_snapshot: delete: properly update parent snapshot with revert data
When deleting external snapshot and parent snapshot is the currently
active snapshot as user reverted to it we need to properly update the
parent snapshot metadata.
After the delete is done the new overlay files will be the currently
used files created when snapshot revert was done, replacing the original
overlay files.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Tue, 4 Apr 2023 12:21:05 +0000 (14:21 +0200)]
qemu_snapshot: add merge to external snapshot delete prepare data
Before external snapshot revert every delete operation did block commit
in order to delete a snapshot. But now when user reverts to non-leaf
snapshot deleting leaf snapshot will not have any overlay files so we
can just simply delete the snapshot images.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Fri, 5 May 2023 15:55:05 +0000 (17:55 +0200)]
qemu_snapshot: introduce external snapshot revert support
When reverting to external snapshot we need to create new overlay qcow2
files from the disk files the VM had when the snapshot was taken.
There are some specifics and limitations when reverting to a snapshot:
1) When reverting to last snapshot we need to first create new overlay
files before we can safely delete the old overlay files in case the
creation fails so we have still recovery option when we error out.
These new files will not have the suffix as when the snapshot was
created as renaming the original files in order to use the same file
names as when the snapshot was created would add unnecessary
complexity to the code.
2) When reverting to any snapshot we will always create overlay files
for every disk the VM had when the snapshot was done. Otherwise we
would have to figure out if there is any other qcow2 image already
using any of the VM disks as backing store and that itself might be
extremely complex and in some cases impossible.
3) When reverting from any state the current overlay files will be
always removed as that VM state is not meant to be saved. It's the
same as with internal snapshots. If user want's to keep the current
state before reverting they need to create a new snapshot. For now
this will only work if the current snapshot is the last.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Fri, 5 May 2023 15:53:54 +0000 (17:53 +0200)]
qemu_snapshot: use VIR_ASYNC_JOB_SNAPSHOT when reverting snapshot
Both creating and deleting snapshot are using VIR_ASYNC_JOB_SNAPSHOT but
reverting is using VIR_ASYNC_JOB_START. Let's unify it to make it
consistent for all snapshot operations.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Wed, 9 Aug 2023 12:28:33 +0000 (14:28 +0200)]
qemuSnapshotCreateQcow2Files: use domain definition directly
To create new overlay files when external snapshot revert support is
introduced we will be using different domain definition than what is
currently used by the domain.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Mon, 6 Mar 2023 14:23:57 +0000 (15:23 +0100)]
qemu_snapshot: use virDomainDiskByName while updating domain def
When creating external snapshot this function is called only when the VM
is not running so there is only one definition to care about. However,
it will be used by external snapshot revert code for active and inactive
definition and they may be different if a disk was (un)plugged only for
the active or inactive definition.
The current code would crash so use virDomainDiskByName() to get the
correct disk from the domain definition based on the disk name and make
sure it exists.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina [Wed, 1 Feb 2023 13:23:58 +0000 (14:23 +0100)]
snapshot_conf: use alternate domain definition in virDomainSnapshotDefAssignExternalNames
Commit <ef3f3884a2432958bdd4ea0ce45509d47a91a453> introduced new
argument for virDomainSnapshotAlignDisks() that allows passing alternate
domain definition in case the snapshot parent.dom is NULL.
In case of redefining snapshot it will not hit the part of code that
unconditionally uses parent.dom as there will not be need to generate
default external file names.
It should be still fixed to make it safe. Future external snapshot
revert code will use this to generate default file names and in this
case it would crash.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Tue, 15 Aug 2023 15:17:14 +0000 (17:17 +0200)]
qemuValidateDomainVCpuTopology: Always validate vcpu count against topology
Historically we've used QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS as witness
that the topology must cover the maximum number ov vcpus. qemu started
to enforce this in qemu-2.5, thus we can now always do the check.
This change also requires aligning the topology in certain test files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 15 Aug 2023 12:20:58 +0000 (14:20 +0200)]
virschematest: Improve detection of 'invalid' XMLs
The output files from 'qemuxml2argvtest' may have the real capability
suffix e.g. 'pci-rom-disabled-invalid.x86_64-latest.xml' which would not
be detected as being invalid and thus causing a test failure.
Change the logic to find '-invalid.' so that we can properly use
'virschematest' with test cases using real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 15 Aug 2023 12:43:20 +0000 (14:43 +0200)]
qemuxml2xmloutdata: Workaround wrong detection of 'disk-cdrom-empty-network-invalid' in virschematest
The 'disk-cdrom-empty-network-invalid' is a special case were the input
XML is invalid according to the schema, but after processing a valid XML
is produced.
This corner case doesn't play well with 'virschematest' which uses the
file suffix to determine whether the file is invalid.
Upcoming patch will change the 'virschematest' condition, which would
start detecting this XML as invalid.
Use the '-active'/'-inactive' suffix for the file, which is possible
with qemuxml2xmltest so that an upcoming patch will not cause test
failure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 11 Aug 2023 14:40:22 +0000 (16:40 +0200)]
qemuxml2xmltest: Modernize all 'DO_TEST_NOCAPS' tests
Convert all tests using the 'DO_TEST_NOCAPS' "fake" capability
invocation to use DO_TEST_CAPS_LATEST and remove the DO_TEST_NOCAPS
macro to prevent further use.
Most of the output file changes are related to default USB controller
type and the CPU becoming defined in the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 15 Aug 2023 08:49:39 +0000 (10:49 +0200)]
qemuxml2argvdata: Convert 'cpu' test cases to use 'x86_64'
Convert the rest of the files using 'qemu-system-i386' to
'qemu-system-x86_64'. The 'cpu*' tests are done separately to emphasise
that there's no change in the output.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Erik Skultety [Mon, 21 Aug 2023 09:42:36 +0000 (11:42 +0200)]
ci: lcitool: Maintain project package deps lists here
Each respective project that lcitool knows about and currently
maintains its list of package dependencies knows best what packages
they actually depend on. If a new dependency is currently needed, first
a change in lcitool is necessary before GitLab jobs and containers can
be updated. Provided a mapping already exists in lcitool (which can
quickly be added as an override via mappings.yml temporarily) we speed
up the whole CI update process by one step.
This patch adds all libvirt deps lists lcitool currently maintains for
libvirt.
Note that as with any overrides (since commit f199dd50) lcitool must be
invoked as '$ lcitool -d/--data-dir ci/lcitool ...'
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Tue, 16 May 2023 17:50:50 +0000 (19:50 +0200)]
conf: Don't default to raw format for loader/NVRAM
Due to the way the information is stored by the XML parser, we've
had this quirk where specifying any information about the loader
or NVRAM would implicitly set its format to raw. That is,
forcing the use of raw format firmware even when qcow2 format
would normally be preferred based on the ordering of firmware
descriptors. This behavior can be worked around in a number of
ways, but it's fairly unintuitive.
In order to remove this quirk, move the selection of the default
firmware format from the parser down to the individual drivers.
Most drivers only support raw firmware images, so they can
unconditionally set the format early and be done with it; the
QEMU driver, however, supports multiple formats and so in that
case we want this default to be applied as late as possible,
when we have already ruled out the possibility of using qcow2
formatted firmware images.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Fri, 26 May 2023 12:40:02 +0000 (14:40 +0200)]
qemu: Generate NVRAM path in more cases
Right now, we only generate it after finding a matching entry
either among firmware descriptors or in the legacy firmware
list.
Even if the domain is configured to use a custom firmware build
that we know nothing about, however, we should still automatically
generate the NVRAM path instead of requiring the user to provide
it manually.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Thu, 11 May 2023 16:29:17 +0000 (18:29 +0200)]
tests: Update firmware descriptor files
These are imported from Fedora 38's edk2 package.
The files that are being replaced date back to RHEL 7 and no
longer represent what libvirt is likely to encounter on an
actual production system.
Notably, the paths have all changed, with both x86_64 and
aarch64 builds now living under /usr/share/edk2 and the AAVMF
name being having been phased out.
Additionally, the 4MB qcow2 format builds have been introduced
on x86_64 and given high priority, effectively making qcow2
the default format across architectures.
The impact of these changes on the test suite is, predictably,
quite severe.
For the cases where paths to firmware files were explicitly
provided as part of the input, they have been adjusted so that
the modern paths are used instead of the legacy ones. Other
than that, input files have been left untouched.
The following expected changes can be seen in output files:
* where qcow2 firmware was used on x86_64, Secure Boot
support is now enabled;
* all ABI_UPDATE test cases for x86_64 now use qcow2
formatted firmware;
* test cases where legacy paths were manually provided
no longer get additional information about the firmware
added to the output XML.
Some of the changes described above highlight why, in order
to guarantee a stable guest ABI over time and regardless of
changes to the host's configuration, it was necessary to move
firmware selection from VM startup time to VM creation time.
In a few cases, updating the firmware descriptors changes the
behavior in a way that's undesired and uncovers latent bugs
in libvirt:
* firmware-manual-efi-secboot-legacy-paths ends up with
Secure Boot disabled, despite the input XML specifically
requesting it to be enabled;
* firmware-manual-efi-rw-modern-paths loses the
loader.readonly=no part of the configuration and starts
using an NVRAM file;
* firmware-manual-efi-nvram-template-nonstandard starts
failing altogether with a fairly obscure error message.
We're going to address all these issues with upcoming changes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Fri, 26 May 2023 16:19:24 +0000 (18:19 +0200)]
tests: Add more tests for firmware selection
Most of these are just additional coverage, but a few demonstrate
bugs in libvirt:
* firmware-manual-efi-nvram-template-nonstandard sees the NVRAM
template path, which was explicitly provided in the XML,
being overridden by the firmware selection machinery;
* firmware-auto-efi-rw* and firmware-manual-efi-rw-legacy-paths
lose the loader.readonly=no setting and thus behave
differently than requested;
* firmware-manual-efi-loader-path-nonstandard fails because an
NVRAM path doesn't get generated.
We're going to address all these issues with upcoming changes.
Note that the firmware-auto-efi-nvram-template-nonstandard
failure is expected: firmware autoselection has been enabled, but
the NVRAM template points to a custom path that's not mentioned
in any of the firmware descriptors and so it can't succeed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Fri, 26 May 2023 15:47:42 +0000 (17:47 +0200)]
qemu: Fix lookup against stateless/combined pflash
Just like the more common split builds, these are of type
QEMU_FIRMWARE_DEVICE_FLASH; however, they have no associated
NVRAM template, so we can't access the corresponding structure
member unconditionally or we'll trigger a crash.
qemu: Fix return value for qemuFirmwareFillDomainLegacy()
The documentation states that, just like the Modern() variant,
this function should return 1 if a match wasn't found. It
currently doesn't do that, and returns 0 instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Tue, 16 May 2023 14:55:41 +0000 (16:55 +0200)]
tests: Turn abi-update.xml into a symlink
Since the idea behind introducing the abi-update variant of
a test is showing that libvirt behaves differently based on
whether the configuration is for a newly-defined domain or an
existing one, we don't want the input files to ever go out of
sync.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 10 Aug 2023 11:33:53 +0000 (13:33 +0200)]
test: qemu: Update qemu-8.1 test data on x86_64
Update to v8.1.0-rc4
Notable changes:
- 'dirty-limit' migration feature added
- 'vcpu-dirty-limit', 'x-vcpu-dirty-limit-period' parameters added
- 'dirty-limit-ring-full-time', 'dirty-limit-throttle-time-per-round' statistics added
- migration statistic of number of skipped zero pages is now deprecated
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 17 Aug 2023 15:43:54 +0000 (17:43 +0200)]
qemu_domain: Drop unused variables from qemuDomainChrDefDropDefaultPath()
In mu previous commits I've moved internals of
qemuDomainChrDefDropDefaultPath() into a separate function
(qemuDomainChrMatchDefaultPath()) but forgot to remove @buf and
@regexp variables which are now unused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 20 Apr 2023 08:16:43 +0000 (10:16 +0200)]
qemu: Move channelTargetDir into stateDir
For historical reasons (i.e. unknown reason) we put channel
sockets into a path derived from cfg->libDir which is a path that
survives host reboots (e.g. /var/lib/libvirt/...). This is not
necessary and in fact for session daemon creates a longer prefix:
Worse, if host is rebooted suddenly (e.g. due to power loss) then
we leave files behind and nobody will ever remove them.
Therefore, place the channel target dir into state dir.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2173980 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Michal Privoznik [Tue, 18 Apr 2023 15:34:12 +0000 (17:34 +0200)]
qemu: Generate shorter channel target paths
A <channel/> device is basically an UNIX socket into guest.
Whatever is sent from the host, appears in the guest and vice
versa. But because of that, the length of the path to the socket
is important (underscored by fact that we derive the path from
domain short name). But there are still cases where we might not
fit into UNIX_PATH_MAX limit (usually 108 characters), because
the path is derived also from other variables, e.g.
XDG_CONFIG_HOME for session domains.
There are two components though, that are needless: "/target/"
and "domain-" prefix. Drop them. This is safe to do, because
running domains have their path saved in status XML and even
though paths are dropped on migration, they are not part of guest
ABI and thus we are free to change them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Erik Skultety [Wed, 16 Aug 2023 08:21:33 +0000 (10:21 +0200)]
ci: Introduce a new 'lcitool' data directory
We've reached a point in lcitool where we can't steer its development
based solely on libvirt's needs IOW there will be times where a local
override of value (e.g. package mapping) will be necessary - an example
of this would be QEMU.
In case of this particular patch we need to add an override for the
cirrus FreeBSD 13 image we request in our CI to fix:
/usr/local/lib/libtasn1.so.6: Undefined symbol "strverscmp@FBSD_1.7"
The reason why we can't/should not make the fix in upstream lcitool
just yet is that we store a libosinfo ID in lcitool's OS target YAML
configs and at the time of writing this patch libosinfo does not have
a corresponding entry/ID for FreeBSD 13.2 so we have to stick with 13.1
in lcitool until they do so.
For the time being, the fix can easily be done on libvirt side as does
this patch.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Erik Skultety [Wed, 1 Feb 2023 14:22:59 +0000 (15:22 +0100)]
ci: build.sh: Join MESON_ARGS and MESON_OPTS
It is quite confusing seeing these two in a call like this one:
$ meson build $MESON_OPTS $MESON_ARGS
One has to ask 'how are they different' and 'shouldn't these be
merged'. In fact, these variables hold very different things and we
should make it more obvious. The problem is that renaming MESON_OPTS to
something more meaningful, like 'MESON_CROSS_OPTS' which is what
MESON_OPTS really does would require changes to lcitool and would
impact Dockerfile generation which in turn might have an impact on
other projects which rely on this lcitool functionality which is risky.
Instead, provide a docstring for the former to supplement the latter
and join the two variables in a single one MESON_ARGS which is then
passed to meson's command line so it's a little less confusing.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Tue, 31 Jan 2023 17:06:53 +0000 (18:06 +0100)]
ci: build.sh: Drop the CI prefix from the CI_{MESON,NINJA}_ARGS vars
Although it is currently consistent with the other variables we define
when running ci in a local container environment, it isn't consistent
with the variable naming we use in GitLab recipes. Since the idea is
to unite the two, we're likely going to drop a few other variables from
the local env configuration anyway, hence this renaming.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
projects / libvirt.git / log