Extend iothreadset to allow configuring the iothread poll-weight value
from the command line.
Add a --poll-weight option to opts_iothreadset and wire it up in
cmdIOThreadSet. If the option is omitted the parameter
is not added to the list and the backend leaves the value unchanged.
Document --poll-weight in the iothreadset section of the virsh manpage
and update the syntax synopsis to include the new option. Extend the
virsh test suite with an iothreadset --poll-weight 3 call followed by
a domstats check that confirms the updated value is reflected.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add support for reading the iothread poll-weight value from QEMU and
exposing it via domain stats.
Add poll_weight and set_poll_weight fields to qemuMonitorIOThreadInfo
and parse the poll-weight property from the QMP query-iothreads
response. The property is optional and only present on newer QEMU
binaries.
Expose the fetched value through the domain stats interface by adding
VIR_DOMAIN_STATS_IOTHREAD_SUFFIX_POLL_WEIGHT and reporting it in
qemuDomainGetStatsIOThread when the value is available.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Document the iothread poll-weight XML attribute in formatdomain.
Extend the description of iothread polling controls to cover the new
poll-weight attribute and how it relates to the existing poll-max,
poll-grow, and poll-shrink settings. Also document the accepted
range and the meaning of zero as a request for the hypervisor
default.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Introduce support for "cmdqv" IOMMU attribute, which enables NVIDIA
Tegra241 CMDQV, an extension for ARM SMMUv3. It supports passthroughs
of physical SMMU-CMDQ linked command queue from host space to a VM.
Reject domain configs that set cmdqv when the QEMU binary lacks the
property.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The virDomainGetGuestInfo() API is exposed as 'guestinfo'
command. Introduce new --devices option for it to reflect
introduction of VIR_DOMAIN_GUEST_INFO_DEVICES type.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Archives (as witnessed by recent reports) hide useful information by
requiring the maintainer to download the archive which may be dangerous.
Recent submissions also contained a lot of fluff inside the archives.
Instruct submitters of security issues to attach files directly instead
of hiding them in an archive.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Use the same heading color as we do for '.. warning::'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add support for enabling HW-accelerated nested SMMUv3 via <accel>
attribute and its additional attributes for ATS, SSID, RIL, and OAS
configuration.
Validate the domain iommu accel attribute in qemu_validate.c when
QEMU lacks this capability. Checking accel is sufficient because ats,
ril, ssidsize, and oas were introduced in the same QEMU release, and
it only makes sense to backport accel, ats, ril, ssidsize, and oas
all together.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Use of email for security disclosures is not a sustainable approach
in the new world with countless LLM assisted security researchers.
The old security approach has been to keep disclosures visible to
a very small number of hand-picked maintainers, on the assumption
that information has to be highly classified. This view is no
longer valid with LLMs assisted research, as multiple people can
report the same flaw within a short window of time. It is assumed
that anyone with access to LLMs will be capable of re-discovering
issues at any time.
As such there is less compelling benefit to limiting the visibility
of disclosures originating with LLMs. Rather than try to distinguish
which disclosures come purely from humans vs those assisted by LLMs,
just assume LLMs will be involved as that is the common case. Thus
make disclosures visible to all maintainers immediately.
By the same rational of repeated re-discovery there is also less
benefit to applying embargoes to issues once a fix is available.
Thus this proposal intends to make CVEs public as soon as a fix
is proposed for merge.
With this new open approach to disclosures, there is then no
reason to have a separate process for disclosing regular bugs vs
security issues. By using the regular bug tracker for security
disclosures, the process can be simplified and gain access to
better tools for tracking & triage than email offers.
Thus the new security disclosure process is simply with bug
tracking process with two add-ons:
* The initial disclosure has the "confidential" flag set
* The use of "CVE::Required" and "CVE::Assigned" labels
to handle CVE allocation.
This is essentially identical to the process adopted by QEMU
last month which has been successful at scaling the triage
process.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Fix three pre-existing typos in the iothread poll sub-element
description:
- Remove spurious 'with' in 'poll with can be used to'
- Add missing closing ')' after the poll-grow/shrink '0' note
- Fix typo 'extensive' -> 'excessive'
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Some guest OSes (e.g. windows) can do an internal crash dump and reboot
after a crash. They unfortunately notify the OS before doing the crash
dump though so we need a new possibility for the <on_crash> action to
keep the VM as is.
This patch introduces 'preserve-running' mode for on_crash and wires it
up into the qemu driver.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fix syntax error in one of the testing examples on alpine-edge image with prefix.
Update CI helper examples to use more recent OS versions:
- Fedora 38 -> Fedora 44
- Debian 11 -> Debian 13
- Debian 10 -> Debian 13
Signed-off-by: Radoslaw Smigielski <rsmigiel@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reflects that the pf firewall check was added in virt-host-validate.
Signed-off-by: Nimish Jain <unauthorizen@gmail.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Add meson option 'libvirtd' to control building of the monolithic
libvirtd, independent from the stateful, daemon-based drivers. E.g.
meson configure -Dlibvirtd=disabled build-dir
The new option defaults to 'auto' and will be enabled when 'driver_libvirtd'
is enabled. Setting libvirtd=disabled skips building the libvirtd binary,
and related items such as config files, systemd units, etc.
The existing option 'driver_libvirtd' controls building libvirtd and all
stateful, daemon-based drivers, making it unsuitable for disabling only
the monolithic daemon. Additionally, 'driver_libvirtd' is used by the
various libvirt-ci projects to produce a minimalistic build.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The detach-interface virsh command requires domain (obviously)
and --type to identify <interface/>. Optionally, --mac can be
provided to chose from multiple interfaces. Well, that renders
--type argument redundant. I mean, if there are but unique MACs
within domain XML, then interface type is implied. If there are
duplicate MACs then --type can help to differentiate, though at
that point detach-device seems like a better fit.
Long story short, make --type optional.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
QEMU's commandline generator picks for virtio video between various
actual device models not only based on the XML definition but also
capabilities present. Since none of the devices is actually ABI
compatible we need to record the actually selected device in the XML.
Introduce 'device' attribute:
<video>
<model type='virtio' heads='1' primary='yes' device='virtio-gpu'/>
which will record the actually selected model so that we can preserve
ABI across restarts on deployment changes but more importantly across
migrations where the deployment differs.
The code specifically avoids an ABI stability check for the new field
because there are already possibly broken configurations that the users
may want to fix by picking the proper model which could be forbidden.
Users are instructed to not set the field in the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This new parameter was added as part of commit ee06a78790 ("remote: allow
passing argv to the ext transport").
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virsh domifannounce is a thin wrapper around the new API
virDomainAnnounceInterface(). Syntax:
virsh domifannounce guestname [interfacename] [parameters]
where the optional interfacename can be either the MAC address of the
interface to announce, or the name of the tap device used to connect
the domain's interface to the real network (if the connection is with
a tap device), and [parameters] is one or more of the following options:
--initial [unsigned integer]
--max [unsigned integer]
--rounds [unsigned integer]
--step [unsigned integer]
For example:
virsh domifannounce myguest 52:54:00:BE:EF:E1 --initial 100
virsh domifannounce other vnet2
virsh domifannounce myguest
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The option corresponds to the
VIR_CONNECT_GET_DOMAIN_CAPABILITIES_SUPPORTED_CPU_FEATURES API flag.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The flag is designed for expanding the CPU model used by host-model. But
the documentation was sometimes describing it as showing all CPU
features supported on the host, which is wrong as the host may support
features that would not be enabled in host-model.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Sections about resource limits are currently placed across the file
in between various device examples. To make it easier to follow,
group them into a single section. This also allows to give
an introduction on the rctl(8) framework once instead of repeating
it for every resource type.
Also, document the memory limitation support added in libvirt 12.4.0.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The difference is that the usual UUID is supposed to be unique per host
and instanceUuid should be unique across the whole cluster. One could
think of them as HUID and CUID (as the first "U" does apparently mean
something else in the Broadcom world). That _would_ be fine for our
scenario. However, that piece of information turns out to be false as
well and the UUID we were using (`config.uuid`, or in VMX the
`uuid.bios`) can be the same in two machines on the same host.
Fortunately the `FindByUuid()` function can also search for VMs based on
their `instanceUuid`, dictated by the so far omitted third parameter.
Unfortunately that parameter is not parsed (or at least properly) before
vSphere API 4.0 (the documentation says 2.0, but we are not using that
namespace and 4.0 is the lowest we can target), which we are not
specifying in the server returns a 500 HTTP error if we use the
`instanceUuid` parameter.
So this patch adds the `SOAPAction: urn:vim25/4.0` header to the cURL
requests which makes that `FindByUuid()` function work even with the
`instanceUuid` set, but without any extra labor.
After that this patch also changes all UUIDs to be parsed from the
`config.instanceUuid` (or `vc.uuid` in the VMX, but there's a fallback
to the old `uuid.bios`) and adjusts tests accordingly.
To give users (and management applications) the possibility to revert
back to the previous (legacy) behaviour a new URI query parameter is
introduced, called `legacy_uuid` which, if set to `1`, still keeps the
code working as it did before this patch.
Last, but not least it changes the parameter to aforementioned function
to be true (unless the legacy behaviour is requested, of course) and
henceforth all searching ought to be done with the more unique ID.
Resolves: https://redhat.atlassian.net/browse/RHEL-174300
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The new XML element is <energytune> under <cputune> following earlier pattern for
resctrl features (cachetune, memorytune). Energytune doesn't currently support
the "tuning" part, only monitoring. I added it as energytune for consistency with
cache and memory features, keeping all resctrl handling under cputune. This also makes
sense with current resctrl architecture - all monitoring groups are part of an
allocation group.
Changes:
- Added <energytune> parsing to domain_conf.c
- Added schema definition in domaincommon.rng
- Documented the element in formatdomain.rst
- Added energytune test
Signed-off-by: Jedrzej Wasiukiewicz <jedrzej.wasiukiewicz@intel.com>
Signed-off-by: Christopher M. Cantalupo <christopher.m.cantalupo@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add VIR_DOMAIN_SETVCPU_ASYNC_UNPLUG for virDomainSetVcpu().
Define a dedicated virDomainSetVcpuBehaviour flag type and wire the
new flag through the QEMU driver. As with setvcpus async unplug,
success indicates request acceptance while final completion is
reported by the vcpu-removed event.
Update the API documentation and add virsh support for the async path to
the setvcpu subcommand.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add VIR_DOMAIN_VCPU_ASYNC_UNPLUG for virDomainSetVcpusFlags().
With this flag, success indicates that QEMU accepted the unplug
request, while final completion is reported by the vcpu-removed
event. Rejected requests continue to be reported by the
device-removal-failed event.
Wire the flag through the QEMU driver, document its semantics, and
add virsh support for the async path in the setvcpus subcommand.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add sections describing usage of the virtio-console device
and about block I/O tuning.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This is most likely referring to past qemu-img behavior. Defaults are
not encoded in libvirt. `qemu-img` behavior is runtime-dependent, with a
current preference towards 'aes-256-xts'.
Signed-off-by: Bruno Renié <brutasse@gmail.com>
FreeBSD supports resource limiting with the rctl(4) framework.
It supports various resource types, including I/O resources.
It allows to limit resources for users, processes, login classes,
and jails.
To apply blkiotune limits set limits for the bhyve process.
I/O related resources supported by rctl(4) are:
readbps filesystem reads, in bytes per second
writebps filesystem writes, in bytes per second
readiops filesystem reads, in operations per second
writeiops filesystem writes, in operations per second
Thus, the actual commands look like:
rctl -a process:$bhyvepid:writebps:throttle=10000000
rctl -a process:$bhyvepid:readbps:throttle=10000000
rctl -a process:$bhyvepid:writeiops:throttle=20000
rctl -a process:$bhyvepid:readiops:throttle=20000
This is different from the current blkiotune modeling in libvirt as
it requires specific device to apply limits to. To adapt this model
to per-domain I/O limits, update domain schema to specify "*" as a
device name.
The rctl(8) may be not available or not enabled, so add a capability
check for that.
Per process rules get removed when the process disappears, so no special
clean up is necessary.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Use the new VIR_DOMAIN_BLOCK_RESIZE_EXTEND to prevent accidentally
shrinking a disk and thus destroying data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The definition of BIT0 in policy element comes from TDX spec, but it makes
confusion for some customers whether 0 or 1 activates debug:
1. We know that "off-TD debug mode" basically means debug from outside the
TD --> 1 activates debug.
2. But when a customer is not aware of the term "off-TD debug" it is very
easy to misinterpret this as "TD debug mode off" --> 1 deactivates debug.
Given that the policy example uses "0x10000001", the second interpretation
even becomes more likely, because a customer may assume that security by
default is applied in the example.
Thus, change the policy in example configuration to "0x10000000" and update
BIT0 definition to be more explicit.
Suggested-by: Fuhry Benny <benny.fuhry@intel.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add '--migrate-disks-target-zero' to pass the list of pre-zeroed disk
images.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously, users had to manually specify a TCP port when starting
a pull-mode backup with an NBD server. A TODO comment in
qemuBackupPrepare() noted this limitation and pointed toward using
virPortAllocator, as done for migration, VNC, and SPICE ports.
When a pull-mode backup is started without specifying a TCP port,
a port is now acquired automatically from the configured range via
virPortAllocatorAcquire(). The port is released when the backup
ends or if startup fails.
Signed-off-by: Lucas Amaral <lucaaamaral@gmail.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This will allow management applications running libvirt without
necessary permissions to pass FD for /dev/iommu with per-process
locked memory accounting enabled.
Kernel uses per-user locked memory accounting by default which may
cause error while starting multiple VMs with host devices using IOMMUFD.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In addition to configuring IOMMUFD for each host device add
configuration for the whole VM. This will be extended to add support for
passing FD to libvirt from management applications.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In the "virtio-scsi" section: "12:0.0" -> "12.0.0".
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
libvirt's <interface> element has for a long time supported adding
<route> sub-elements to specify arbitrary routes to be added to the
guest OS networking, but historically this has only worked for LXC
guests. If you tried to add <route> to the interface of a QEMU guest,
it would be rejected.
passt networking doesn't support setting *any arbitrary* route but it
does support setting a default route (using the passt commandline
"--gateway" parameter). A default route is really just a "route with
unspecified destination/prefix", so a default route can be specified
in libvirt XML with:
<route gateway='192.168.0.1'/>
Attempts to give a specified destination, prefix, or metric will
result in a validation error.
Resolves: https://issues.redhat.com/browse/RHEL-46602
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The Linux/libnl version of virNetDevIPRouteAdd() has always had code
that would use "0.0.0.0" (or "::" for IPv6) for the route's
destination address if none was specified, but 1) our validation code
has always required it to be specified anyway, 2) the FreeBSD version
of virnertDevIPRouteAdd() expected that it would be specified, and 3)
virNetDevIPRouteFormat() also expected route->address to be
valid. This patch fixes those 3 deficiencies, so that this XML now
works:
<route gateway='1.2.3.4'/>
i.e. it is the same as:
<route address='0.0.0.0' prefix='0' gateway='1.2.3.4'/>
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Document the fact that the existing flags which apply to
NVRAM files also do the right thing when varstore files are
used instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Benjamin
Jaehoon Kim
Nathan Chen
Michal Privoznik
Peter Krempa
Daniel P. Berrangé
Radoslaw Smigielski
Nimish Jain
Jim Fehlig
Mark Cave-Ayland
Laine Stump
Jiri Denemark
Roman Bogorodskiy
Martin Kletzander
Jedrzej Wasiukiewicz
Akash Kulhalli via Devel
Bruno Renié
Zhenzhong Duan
Lucas Amaral
Pavel Hrdina
Andrea Bolognani