The QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI_DYNAMIC_MEMSLOTS reflects
whether QEMU is capable of .dynamic-memslots for virtio-mem.
Use it when validating domain configuration.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Starting from v8.2.0-rc0~74^2~2 QEMU has .dynamic-memslots
attribute for virtio-mem-pci device. Introduce a capability which
reflects that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Introduced in v8.2.0-rc0~74^2~2, QEMU now allows setting
.dynamic-memslots attribute for virtio-mem-pci devices. When
turned on, it allows memory exposed to guest to be split into
multiple memslots and thus smaller memory footprint (see the
original commit for detailed explanation).
Therefore, introduce new <target/> attribute which will control
that QEMU knob.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In v9.10.0-rc1~103 the remote driver was switched to g_auto() for
client RPC return parameters. But whilst doing so a small bug
slipped in: previously, when virDomainGetBlockIoTune() was called
with *nparams == 0, the function set *nparams to the number of
supported params and zero was returned (so that client can
allocate memory and call the API second time). IOW - the usual,
old style of APIs where we didn't want to allocate memory on
caller's behalf. But because of this bug, a negative one is
returned instead.
Fixes: 501825011c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are a number of cases in which we want to test both the
normal behavior and the ABI_UPDATE behavior for the same input
XML.
The way this is currently implemented is ad-hoc, and involves
symlinking the input XML as well as coming up with an
alternative name for the ABI_UPDATE variant: in most cases the
-abi-update suffix is added, but since this is not enforced
there are a couple of cases where we do something else instead.
To make things simpler and more consistent, implement the
naming convention at the macro level. This way, we no longer
need to create any symlinks for the input file, and the output
files are automatically named correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The input file is a symlink for the ppc64-usb-controller input
file, so the output files are identical as well. It's just an
unnecessary duplicate.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Encryption secrets are considered a format dependency, even
when being used by the storage node itself, as in the case of
using encryption engine=librbd.
Currently, the storage node is created (blockdev-add) before
creating the format dependencies (including encryption secrets).
As a result, when trying to perform a blockcopy when the target
disk uses librbd encryption, an error of this form is returned:
"error: internal error: unable to execute QEMU command 'blockdev-add': No secret with id 'libvirt-5-format-encryption-secret0'"
To overcome this error, we change the order of commands so that
format dependencies are created BEFORE creating the storage node.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
After v9.1.0-rc1~116 we track whether it's us who created a
macvtap or not. But when updating a vNIC its definition might be
replaced with a new one (though, ifname is not allowed to
change), e.g. to reflect new QoS, link state, etc.
Now, the fact whether we created macvtap for given vNIC is stored
in net->privateData->created. And replacing definition is done by
simply freeing the old definition and making the pointer point to
the new one. But this does not preserve the 'created' flag, which
in turn means when a domain is shutting off, the macvtap is not
removed (see loop inside of qemuProcessStop()).
Copy this flag into new definition and leave a note in
_qemuDomainNetworkPrivate struct.
Fixes: 61d1b9e659
Resolves: https://issues.redhat.com/browse/RHEL-22714
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Turns out, there are two ways to specify an empty CD-ROM drive in
a .vmx file:
1) .fileName = "emptyBackingString"
2) .fileName = ""
While we do parse 1) successfully, the code does not accept 2)
and an error is reported. Modify the code to treat both cases the
same.
Resolves: https://issues.redhat.com/browse/RHEL-19380
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The libvirt created linux bridge has a configurable value "delay",
the default value is "0", but it will not take effect. That's because
kernel has a minimum value for linux bridge. Add some explanation
about it in the document.
Signed-off-by: Yalan Zhang <yalzhang@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After guest is started, or we are reconnecting to already running
one (after daemon restart), qemuProcessRefreshRxFilters() is
called to refresh rx-filters (basically MAC addresses of guest
NICs) as they might have changed while we were not running (for
the case when reconnecting to an already running guest), or we
need to enable them by running a command (for freshly started
guest - see processNicRxFilterChangedEvent()).
Now, our XML parser allowed trustGuestRxFilters attribute for all
types and models of <interface/> while in reality, only virtio
model AND TUN/TAP based types can see MAC address changes. For
other combinations, QEMU reports an error.
This all means that when the daemon is restarted and it
reconnects to a guest with, well invalid configuration, or when
such guest is restored from a saved image, or migrated then we
issue the monitor command, to which QEMU replies with an error
which is then propagated to users:
error: internal error: unable to execute QEMU command 'query-rx-filter': invalid net client name: hostdev0
While on one hand users should fix their configuration (and after
v10.0.0-rc1~123 they can do that even on live domains), libvirt
can also has some logic built in that prevent issuing the command
in the first place (for obviously wrong cases).
Fixes: 060d4c83ef
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This should fix build failures when a daemon code is compiled before the
included *_protocol.h headers are ready, such as:
FAILED: src/virtqemud.p/remote_remote_daemon_config.c.o
../src/remote/remote_daemon_config.c: In function ‘daemonConfigNew’:
../src/remote/remote_daemon_config.c:111:30: error:
‘REMOTE_AUTH_POLKIT’ undeclared (first use in this function)
111 | data->auth_unix_rw = REMOTE_AUTH_POLKIT;
| ^~~~~~~~~~~~~~~~~~
../src/remote/remote_daemon_config.c:111:30: note: each undeclared
identifier is reported only once for each function it appears in
../src/remote/remote_daemon_config.c:115:30: error:
‘REMOTE_AUTH_NONE’ undeclared (first use in this function)
115 | data->auth_unix_rw = REMOTE_AUTH_NONE;
| ^~~~~~~~~~~~~~~~
../src/remote/remote_daemon_config.c: In function
‘daemonConfigLoadOptions’:
../src/remote/remote_daemon_config.c:252:31: error:
‘REMOTE_AUTH_POLKIT’ undeclared (first use in this function)
252 | if (data->auth_unix_rw == REMOTE_AUTH_POLKIT) {
| ^~~~~~~~~~~~~~~~~~
or
FAILED: src/virtqemud.p/remote_remote_daemon_dispatch.c.o
In file included from ../src/remote/remote_daemon.h:28,
from ../src/remote/remote_daemon_dispatch.c:26:
src/remote/lxc_protocol.h:13:5: error:
unknown type name ‘remote_nonnull_domain’
13 | remote_nonnull_domain dom;
| ^~~~~~~~~~~~~~~~~~~~~
In file included from ../src/remote/remote_daemon.h:29,
from ../src/remote/remote_daemon_dispatch.c:26:
src/remote/qemu_protocol.h:13:5: error:
unknown type name ‘remote_nonnull_domain’
13 | remote_nonnull_domain dom;
| ^~~~~~~~~~~~~~~~~~~~~
src/remote/qemu_protocol.h:14:5: error:
unknown type name ‘remote_nonnull_string’
14 | remote_nonnull_string cmd;
| ^~~~~~~~~~~~~~~~~~~~~
...
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
These values are currently unsupported for ssh disks, and in fact aren't
even parsed for ssh disks. So while this didn't result in any test
errors, we can remove them from the test input files.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
When trying to start nbdkit-backed disks in backing chains, we were
accidentally always checking the private data of the top of the chain
instead of using the loop variable.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Division between integers will also be integer.
Thus, to preserve fractional part explicitly
convert first operand to double.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 28d54aab05 ("examples: Introduce domtop")
Signed-off-by: Egor Makrushin <emakrushin@astralinux.ru>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Since commit 4af3cbafdd the function always returns 0, so it is
possible to make this function void and remove return value checks.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
Unify the output directory. Symlinks needed to be adapted to work
properly, but the 'qemuxml2argvdata' symlink can now be removed.
The virschematest exceptions needed to be moved to the proper directory
once the files are moved.
The unification of the output directory now also ensures that files
won't be forgotten once tests are removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Unify the naming of the data directory with the test name.
'tests/qemuxml2argvdata' is for the time converted to a symlink to
'qemuxmlconfdata', to preserve the symlinks in
'tests/qemuxml2xmloutdata'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Remove leftover output files. The list of files was identified by
temporarily hacking testConfXMLEnumerate to also enumerate
'tests/qemuxml2xmloutdata' directory.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Include also the output files in the validation of used files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Populate the output filename strings only when the files are expected to
exist, so that other logic can be based on the presence of the strings
rather than having to re-check the test flags for expected state.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There's plenty symlinks in qemuxml2argvdata and qemuxml2xmlout
directories pointing to other files in the same directory. It makes no
sense to check those files twice, thus we can simply skip symlinks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Current implementation of virDomainMemoryDefCheckConflict() does
only a one way comparison, i.e. if there's a memory device within
def->mems[] which address falls in [mem->address, mem->address +
mem->size] range (mem is basically an iterator within
def->mems[]). And for static XML this works just fine. Problem is
with hot/cold plugging of a memory device. Then mem points to
freshly parsed memory device and these half checks are
insufficient. Not only we must check whether an existing memory
device doesn't clash with freshly parsed memory device, but also
whether freshly parsed memory device does not fall into range of
already existing memory device.
Resolves: https://issues.redhat.com/browse/RHEL-4452
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
meson wraps python scripts already on win32, so we end up with these
failing commands:
[185/868] Generating src/rpc/virnetprotocol.h with a custom command
FAILED: src/rpc/virnetprotocol.h
"sh" "libvirt/scripts/meson-python.sh" "F:/msys64/ucrt64/bin/python3.EXE" "F:/msys64/ucrt64/bin/python.exe" "libvirt/scripts/rpcgen/main.py" "--mode=header" "../src/rpc/virnetprotocol.x" "src/rpc/virnetprotocol.h"
SyntaxError: Non-UTF-8 code starting with '\x90' in file F:/msys64/ucrt64/bin/python.exe on line 1, but no encoding declared; see https://peps.python.org/pep-0263/ for details
The issue was introduced in a62486b95f commit.
These changes are similar as e06beacec2 commit.
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Adapt the configuration of redirects from the server hosting libvirt.org
The redirect to the 'libvirt-console-proxy' Golang module is not adapted
as it doesn't exist on the current server.
NOTES:
- The redirects are currently configured for hosting via the
'gitlab.io/libvirt' URI. For hosting via custom domain it will need
to be rewritten to drop the '/libvirt' prefixes.
- gitlab pages doesn't currently support redirects to outside content,
thus most of the redirects don't actually work:
https://gitlab.com/gitlab-org/gitlab-pages/-/issues/601
- The redirects file is only installed in the webpage job but is not
actually distributed.
- The validity of the redirects can be checked by visiting:
https://libvirt.gitlab.io/_redirects
Having them installed allows us to validate them before we'll be
switching to use gitlab pages completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
On pushes to master publish the webpage (built in the 'website_job' job)
via gitlab pages. The 'pages' job uses the default image that gitlab
assumes as it's consuming artifacts from an existing job and naming
them properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The latest lcitool merged the 'prebuilt-env' and 'local-env' jobs into
one which use variables to pick up the right environment and steps
rather than duplicating everything.
Regenerate the generated job definitions, fix the helper definitions
and also fix the manually defined jobs (website-job).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Rewrite the function so that it's more compact and easier to
extend as new architectures, which will likely come with
multibus support right out the gate, are introduced.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It belongs next to qemuDomainSupportsPCI().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way the function is currently written sort of obscures this
fact, but ultimately we already unconditionally assume PCI
support on most architectures.
Arm and RISC-V need some additional checks to maintain
compatibility with existing configurations but for all future
architectures, such as the upcoming LoongArch64, we expect PCI
support to come out of the box.
Last but not least, the functions is made const-correct.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's no longer used anywhere.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For all versions of QEMU that we support, the virt machine type
has a hard dependency on this device, so we can stop checking
whether the capability is present and just use it unconditionally.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For all supported QEMU version, the virt machine type has a hard
dependency on PCI support, so if we want to test virtio-balloon
together with virtio-mmio we have to either request that
explicitly or trick libvirt by masking capabilities. Do the
former instead of the latter.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Drop everything that's not directly related to the scenario
being tested.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All of these are either a subset of other tests, or provide
coverage for scenarios that are not really possible: for all
versions of QEMU that we support, the virt machine type has a
hard dependency on the generic PCIe controller, which means
that we will never need to fall back to virtio-mmio.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Even though virtio-mmio is no longer the default on either
architecture, and likely nobody is using it at this point, we
still provide a way to opt into virtio-mmio usage and want to
keep existing guests working. Add explicit test suite coverage
for this scenario.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After commit 1d8454639f (libvirt 3.0.0), the default address
type for aarch64/virt guests is PCI. These tests are then
pointless, as they are just a subset of other tests, and the
comment attached to them inaccurate.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bus name for the default PHB is always "pci.0".
Fixes: 937f319536
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is the same as the existing pseries-phb-simple, except that
each of the controllers is given a user alias. If we tried to
start the resulting guest, we'd get an error:
Bus 'ua-phb0' not found
This is because, at the QEMU command line level, the default PHB
is not represented and so it can't be given a custom alias. We're
going to address this issue in a follow-up commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We want to make sure that not only the controllers themselves
are added correctly, but also that devices attached to them
get assigned the expected bus value. In order to do that add
some devices, one per controller.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
