Register cleanup function for vshTableRow and use it to simplify cleanup
in 'vshTableRowAppend'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'error' label is not needed, we can directly return failure from the
only error.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
FreeBSD 15.x updated posix_fallocate() to return EOPNOTSUPP
instead of EINVAL when the operation is not supported.
Quoting posix_fallocate(2):
Previous versions of posix_fallocate used EINVAL to indicate that the
operation is not supported by the file system, as specified in IEEE Std
1003.1 (“POSIX.1”) Base Specifications, Issue 7. IEEE Std 1003.1
(“POSIX.1”) Base Specifications, Issue 8 switched to requiring EOPNOTSUPP
for this error case. ZFS adopted the latter convention in FreeBSD 15.0,
and the remaining filesystems in base adopted it in FreeBSD 15.1.
Update safezero_posix_fallocate() to handle this return value
along with EINVAL to fix the waterfall down to safezero_slow()
for filesystems that do not support that.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit 32f7db0989 added support for superwide SCSI, but did not change
the disk ID calculation which resulted in a possible duplicate. Change
it to calculate based on the (already decided) maximum of SCSI units per
bus and add a (well, modify existing) test case.
Fixes: 32f7db0989
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add a FreeBSD implementation of the virArpTableGet() function.
Update the bhyve driver's bhyveDomainInterfaceAddresses()
to use it for the VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP
source type.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
prlsdkGetNetAddresses allocates addr via g_new0 on each loop iteration.
If PrlStrList_GetItem fails and jumps to cleanup, addr is leaked since
prlsdkParseNetAddress (which previously freed it) is never reached.
Fix by using g_autofree for addr in prlsdkGetNetAddresses so it is freed
at scope end, and remove the VIR_FREE(addr) from prlsdkParseNetAddress
to avoid double-free, as callers should manage their own memory.
Signed-off-by: Shiva Shankar <shivanayak@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>
Switch to using systemd's native UMask= directive, instead of using
umask directly in ExecStart=.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
MemAvailable was introduced in kernel version 3.10 (and it was even
backported to older kernels in some distributions) and has been
a quite popular method to estimate the available method (totally fully
amount + reclaimable amount).
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The Hyper-V driver does not support specifying <memory> or <disks> in
the snapshot xml and rejects those configurations.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When invoking a method in WMI, it can either return synchronously or
asynchronously (with return value 4096). In the latter case, the output
parameters of the method are not present in the method response xml
document. We have to fetch the output parameters via associations with
the Job object that is returned in the method response.
the hypervInvokeMethod() function already partially handles the async
case by polling the job until it fails, completes successfully, or
times out. This patch adds a utility function to fetch a named output
parameter from a given method response xml document. It handles both
synchronous and asynchronous cases.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
If a qcow2 image uses a 'data-file' on a local block device we can still
honour VIR_DOMAIN_BLOCK_RESIZE_CAPACITY but use the capacity of the
data-file instead.
The code is modified to first pick the virStorageSource which we'll
probe for size based on the config of the VM and uses to determine the
new size.
Resolves: https://redhat.atlassian.net/browse/RHEL-155809
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@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>
Introduce a new flag VIR_DOMAIN_BLOCK_RESIZE_EXTEND which will prevent
accidental shrinking of the block device.
Warn callers that they ought to use it.
While this won't prevent any old uses without the flag (which we
couldn't change due to our API guarantees) it will give the users tools
to handle the resizing of devices more safely.
Implement it in the qemu driver.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will want to add more extensive docs for one of the new
flags so this format will make it more readable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Overriding the blockio settings for disk passthrough via
"<disk device='lun'>" doesn't make sense and in fact the 'scsi-block'
device in qemu doesn't even expose the appropriate properties:
qemu-system-x86_64: -device {"driver":"scsi-block","bus":"scsi0.0","channel":0,"scsi-id":0,"lun":0,"drive":"libvirt-1-format","id":"scsi0-0-0-0","logical_block_size":512,"physical_block_size":512}: Property 'scsi-block.physical_block_size' not found
Reject those at validation.
Resolves: https://redhat.atlassian.net/browse/RHEL-145937
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@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>
The current qemuDomainGetHostnameLease() implementation
jumps to the "endjob" label when it finds hostname.
As the label is defined after "ret = 0",
qemuDomainGetHostnameLease() returns -1 in this case.
That works because in qemuDomainGetHostname() it is used like that:
...
if (qemuDomainGetHostnameLease(vm, &hostname) < 0)
goto cleanup;
...
cleanup:
virDomainObjEndAPI(&vm);
return hostname;
}
So it works, but it looks confusing. To make more consistent,
use 'break' in qemuDomainGetHostnameLease() when the hostname
is found, so it returns 0 in this case.
Fixes: a4a5827c9f
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Implement the domainInterfaceAddresses and domainGetHostname APIs.
These APIs could use multiple sources of information, though
for bhyve only the 'lease' source is supported.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Wthout this change, the tapfd path would only be appended to a domain's
profile when the device is hotplugged (either during domain start or
normal operation). Operations which regenerate the profile (blockcommit,
etc) will cause this path to be dropped from the profile.
Since the domain status XML now includes the path to the tap device,
include it in the profile.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/692
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2126574
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
VIR_DOMAIN_DEF_FORMAT_STATUS is used to include disk & network
privateData elements in the domain XML, which contain misc information
that should be available to the virt-aa-helper when generating rules.
For now, this will be used in a subsequent patch to pass tap paths to
the virt-aa-helper.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
Introduce a read-only `tapfd` element for direct interfaces (macvtap),
which contains the path to the backing tapfd for that interface
(e.g. `/dev/tapXX`).
The element is only included when the domain is being formatted for
internal consumption (VIR_DOMAIN_DEF_FORMAT_STATUS) and is not accepted
in user-provided XML (!VIR_DOMAIN_DEF_PARSE_INACTIVE).
This will be used by the AppArmor security driver when re-generating
profiles.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
Add missing g_autofree as the code looks like it was already written to
use it.
Fixes: 6316f26cd2
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Use g_auto() for every virBuffer in this function to make sure none of
them will leak memory. It is not necessary to use on all of them because
for some of the buffers virXMLFormatElement() is called before any
return from the function but for consistency reasons it's better to use
g_auto() for all cases.
Fixes: d9b34ad12b
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that after previous commit the wait for udev to settle down
is done right after device creation, there's no need to have
additional wait in virNetDevMacVLanTapOpen(). It's effectively a
dead code. Remove it.
Tested-by: Johannes Segitz <jsegitz@suse.de>
Reviewed-by: Laine Stump <laine@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When a macvtap interface is created (e.g. during domain startup
or on device hotplug) libvirt then open corresponding /dev/tapNN
in order to pass FDs to the hypervisor. These FDs are labelled
before passing, but if creating the interface and open() happen
in quick succession, i.e. when udev did not had chance to run,
then the /dev/tapNN node might have default SELinux label
(device_t) instead of correct one (tun_tap_device_t). This then
leads to AVC messages, like the following:
type=AVC msg=audit(1774535384.365:1238): avc: denied { open } for pid=6765
comm="rpc-virtqemud" path="/dev/tap33" dev="devtmpfs" ino=805
scontext=system_u:system_r:virtqemud_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
Therefore, allow udev to settle down after macvtap is created (by
calling virWaitForDevices()).
Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/866
Tested-by: Johannes Segitz <jsegitz@suse.de>
Reviewed-by: Laine Stump <laine@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When running in session/unprivileged mode, nearly all paths are
prefixed with the returns from one of glib's g_get_user_*_dir()
functions, which in turn base their selected paths on the settings of
a few items in the user's environment ($XDG_*, or a subdirectory of
$HOME if the relevant $XDG_* isn't set).
This patch logs the settings of these directories in the log banner in
an attempt to help diagnose the problem when a file/socket open/create
fails.
An example of the banner:
libvirt version: 12.3.0, package: 1.fc43 (Unknown, 2026-04-07-22:43:30, vhost)
hostname: 83be0e173e02, uid: 107
home dir: '/' (HOME='/')
runtime dir: '/.cache' (XDG_RUNTIME_DIR='(unset)')
config dir: '/.config' (XDG_CONFIG_HOME='(unset)')
log dir: '/.cache' (XDG_CACHE_HOME='(unset)')
libvirt: XML-RPC error : Cannot create user runtime directory '/.cache/libvirt': Permission denied
Resolves: https://redhat.atlassian.net/browse/RHEL-70222
Resolves: https://redhat.atlassian.net/browse/RHEL-105490
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
As libvirt is used more and more in unprivileged/session mode,
file/socket permission errors have become more common. This patch adds
the uid of the current libvirt process (whatever it may be) to the
"hostname" line in the log banner (the first thing sent to every log
target after the process starts).
This is a first step in providing more useful info for session mode
users. We can expand on this idea to include additional generally
useful stuff about the environment we're running in. (We just need to
remember that in this context we can't call anything that could lead
to recursively calling the logging system (i.e. we can't call any code
that reports an error, or a VIR_WARN, etc))
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The same thing happens for each line of the log banner:
1) A helper function is called that a) creates a "raw" string (just
the desired info, e.g. version string) and b) calls
virLogFormatString() to create a "cooked" version of the string
(containing thread-id and log priority)
2) the outputFunc for the target is called with strings (a) and (b)
By making a helper that does (1b) & (2), we can further reduce the
amount of redundant code that needs to be written to add another line
to the banner - now all we need to do is:
1) create the raw string
2) call the helper, sending it the raw string
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The same several lines were repeated, once in a loop iterating through
all log targets, and again to output to stderr when there are no log
targets specified. This just moves those lines into a helper function,
making it easier and less error prone to add additional info to the
banner that is logged each time a daemon starts logging.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For some reason there were some uses of this struct where "struct
_virLogMetadata" was used instead of just using the typedef
"virLogMetadata" (they are both defined in the same file -
virlog.h). Possibly at one point the struct was in virlog.c and
outsiders could only see it as an opaque object, but even if that was
the case, there are already cases of the typedef being used outside of
virlog.c, and constinuing to use "struct _virLogMetadata" in some
places both looks too much K&R 1st edition and might incorrectly imply
to someone that there *is* data abstraction/hiding going on when there
really isn't. So let's just always use plain virLogMetadata.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The message previously just said "Could not create log directory", but
didn't provide the name of the directory, which could be helpful in
determine why the failure occured.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemuDomainOpenFile() only acts on the 'dac' driver, where 'label'
and 'imagelabel' are always identical (see virSecurityDACGenLabel()).
So there's nothing TODO here
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Every caller passes this in, we can depend on it being non-NULL.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When fs->sock is set, virtiofs is externally managed, and most
of qemu_virtiofs.c should do nothing.
Some qemu_virtiofs.c functions handle this case, but some require the
caller to guard against it.
Standardize on making this the responsibility of qemu_virtiofs.c
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When support for vhostuser devices was added, it was just
blanket-prevented from making any changes to a live device with
update-device. This is problematic because the link state of a network
device is modified with update-device. Most all of the parameters of a
vhostuser network device are individually checked within
qemuDomainChangeNet() anyway, so we don't need to just do a BRS (Big
Red Switch) forbidding of any change. We do need to check for
modifications to the socket parameters (path, type, reconnect) though,
since those are vhostuser-specific (we're not already checking for
them elsewhere) and they can't be changed on a live interface.
Resolves https://redhat.atlassian.net/browse/RHEL-152533
Resolves: https://bugs.passt.top/show_bug.cgi?id=198
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Somehow we've never checked for this, and nobody has ever tested for
it or complained about it, but certainly attempting to change a user
or vhostuser network device to/from a passt backend wouldn't work. Now
we check for it and log an error.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We would leak ret if the remaining two virJSONValueObjectAdd() calls
would fail but it will not happen with current code.
Fixes: c7570bbef8
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Refactor the configuration data setup to pass the localstatedir variable
directly during initialization.
No functional change intended.
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Peter Krempa
Roman Bogorodskiy
Martin Kletzander
Andi Chandler
Fco. Javier F. Serrador
shivanayak
Bruno Renié
Jim Fehlig
Takashi Kajinami
Jonathon Jongsma
Zhenzhong Duan
Wesley Hershberger
Pavel Hrdina
Michal Privoznik
Laine Stump
Cole Robinson
Arun Menon