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>
This will be used to configure the backing storage used by the
uefi-vars QEMU device.
Dealing with the element itself is trivial, however we have to
refactor the existing code which deals with the loader and nvram
elements slightly: in particular, we can no longer perform an
early exit if those elements are absent.
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>
Recommend that users take advantage of firmware autoselection
and discourage providing paths manually.
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>
The new name is much more accurate since the documentation is
applicable to firmware other than BIOS, notably UEFI.
An empty container is used to keep old links working.
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>
Bhyve supports vcpu pinning using the `-p vcpu:hostcpu`
argument. This argument can be specified multiple times for the same
vcpu to pin it to multiple hostcpu's.
Bhyve currently does not allow to change vcpu pinning configuration for
the VM that is already running.
Use this to support domain's vcpupin configuration such as:
<cputune>
<vcpupin vcpu="0" cpuset="1,2,3"/>
</cputune>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add config and docs allowing enabling latency histogram collection for
block device operations.
This patch sets up the docs, schema and XML infrastructure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Separate the timed statistics group and link to the fields which are
returned by it.
Prepare the wording for more statistics configs in the future.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
All other paragraphs in this section use 2 spaces after hyphen, fix the
recently added section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add documentation and constants for constructing the stats field names
for latency histograms and expose them in the qemu driver:
Example:
block.1.latency_histogram.read.bin.count=9
block.1.latency_histogram.read.bin.0.start=0
block.1.latency_histogram.read.bin.0.value=0
block.1.latency_histogram.read.bin.1.start=10
block.1.latency_histogram.read.bin.1.value=0
block.1.latency_histogram.read.bin.2.start=100
block.1.latency_histogram.read.bin.2.value=0
block.1.latency_histogram.read.bin.3.start=1000
block.1.latency_histogram.read.bin.3.value=1047
block.1.latency_histogram.read.bin.4.start=10000
block.1.latency_histogram.read.bin.4.value=2131
block.1.latency_histogram.read.bin.5.start=100000
block.1.latency_histogram.read.bin.5.value=0
block.1.latency_histogram.read.bin.6.start=1000000
block.1.latency_histogram.read.bin.6.value=0
block.1.latency_histogram.read.bin.7.start=10000000
block.1.latency_histogram.read.bin.7.value=0
block.1.latency_histogram.read.bin.8.start=100000000
block.1.latency_histogram.read.bin.8.value=0
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As it turns out, some users of the hyperv "host-model" mode might
want to override the hypervisor defaults. For instance disable a
feature that's on by default, or vice versa. Currently, this is
not possible because as soon as our XML parser sees the
"host-model" mode it exits early and skips parsing of individual
features (for "custom" mode). Well, do not return early and parse
the rest.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Document the new encryption of secrets feature in secretencryption.rst.
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The 'migration' attribute for the '<reservations>' element allows to
control the persistent reservation migration feature independently of
the machine type default.
Add the XML plumbing and qemu support.
We consider it ABI for now since it influences qemu migration protocol.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In PCI assignment scenario the virtio-iommu needs to know the
guest page size also known as granule. Expose it as an attribute
to the <driver/> element of a virtio-iommu.
This is possibly interesting only for aarch64 since it supports
virtio-iommu and also supports running guests with different page
size than the host.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Radoslaw Smigielski
Nimish Jain
Jim Fehlig
Michal Privoznik
Peter Krempa
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
Arun Menon
Maximilian Martin