This function is a specialized version of
qemuDomainGetMemLockLimitBytes() for PPC64. Simplifying it in the same
manner as the previous patch has the nice side effect of accounting
for the possibility of an mdev device
(I don't know if mdev devices are supported on PPC, but even if not
then a) the additional check for mdev devices gained by using
qemuDomainNeedsVFIO() in place of open coding will be an effective
NOP, and b) if mdev devices are supported on PPC64 in the future, this
function will be prepared for it).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This function goes through a loop checking if each hostdev is a VFIO
or mdev device, and then later it calls virDomainDefHasNVMEDisk(). The
function qemuDomainNeedsVFIO() does exactly the same thing, so let's
just call that instead.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This function returns true if the domain has any interfaces that are
type='vdpa'.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Generated by the following spatch:
@@
expression a, b;
@@
+ b = g_steal_pointer(&a);
- b = a;
... when != a
- a = NULL;
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The ESX implementation of virConnectListAllDomains() follows
pretty much implementations in other drivers: it has local array
of virDomainPtr-s which (if requested by caller) is filled by
actual domains or not (if the caller is interested only in the
count of domains).
Anyway, in case of the former, the passed @domains argument is
set to the local array, which is then set to NULL to prevent it
from freeing under cleanup label. Pretty standard pattern.
Except, the local array is set to NULL always. Even if the local
array is not stolen. Fortunately, this doesn't lead to a memory
leak, because if caller is not interested in the array, none is
allocated. But it doesn't set good example and also breaks my
spatch rules.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Some SRIOV PFs don't have a netdev associated with them (the spec
apparently doesn't require it). In most cases when libvirt is dealing
with an SRIOV VF, that VF must have a PF, and the PF *must* have an
associated netdev (the only way to set the MAC address of a VF is by
sending a netlink message to the netdev of that VF's PF). But there
are times when we don't need for the PF to have a netdev; in
particular, when we're just getting the Switchdev Features for a VF,
we don't need the PF netdev - the netdev of the VF (apparently) works
just as well.
Commit 6452e2f5 (libvirt 5.1.0) *kind of* made libvirt work around PFs
with no netdevs in this case - if virNetDevGetPhysicalFunction
returned an error when setting up to retrieve Switchdev feature info,
it would ignore the error, and then check if the PF netdev name was
NULL and, if so it would reset the error object and continue on rather
than returning early with a failure. The problem is that by the time
this special handling occured, the error message about missing netdev
had already been logged, which was harmless to proper operation, but
confused the user.
Fortunately there are only 2 users of virNetDevGetPhysicalFunction, so
it is easy to redefine it's API to state that a missing netdev name is
*not* an error - in that case it will still return success, but the
caller must be prepared for the PF netdev name to be NULL. After
making this change, we can modify the two callers to behave properly
with the new semantics (for one of the callers it *is* still an error,
so the error message is moved there, but for the other it is okay to
continue), and our spurious error messages are a thing of the past.
Resolves: https://bugzilla.redhat.com/1924616
Fixes: 6452e2f5e1837bd753ee465e6607ed3c4f62b815
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With this, incomplete XML without <frames/> for <rx/> in coalesce
won't raise error as before. It will leave the coalesce parameter
empty, thanks to passing it as a parameter and return an integer
to indicate error state - previously it returned pointer (or NULL
for both error and incomplete XML).
I also added a test case to test this functionality in the
qemuxml2xmltest.
The code went through some refactoring:
* change of a condition
* addition of a parameter
* change of order, that allowed removal of VIR_FREE
* removal of redundant labels and variables
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1535930
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit ac87d3520ad5 consolidated common cgroup code between the QEMU and
lxc drivers in domain_cgroup.c. In this process, in
virDomainCgroupSetupDomainBlkioParameters(), a call to
virCgroupGetBlkioWeight() went missing.
The result is that 'virsh blkiotune' is setting the blkio.weight for the
guest in the host cgroup, but not on the domain XML, because
virCgroupGetBlkioWeight() is also used to write the blkio.weight value
in the domain object.
Fix it by adding the virCgroupGetBlkioWeight() call in the
virDomainCgroupSetupDomainBlkioParameters() helper.
Fixes: ac87d3520ad542d558854a72b0ae0a81fddc6747
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1941407
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Previously we'd assign the default checkpoint bitmap names in
virDomainCheckpointAlignDisks. In cases when the checkpoint is redefined
without a domain XML virDomainCheckpointAlignDisks is not called.
Add an explicit call to virDomainCheckpointDefAssignBitmapNames to
restore functionality.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When a checkpoint is redefined without providing the domain XML, we
might end up with a definition where the per-disk bitmap name is not
set. Trying to delete such checkpoint would lead to a crash.
Refuse such deletion.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1941600
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Base the detection on the presence of the 'secret' qom-type entry, which
isn't conditionally compiled in qemu.
All caps-based test now switch to using JSON for -object.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Skip the lossy conversion to legacy commandline arguments by using the
JSON props directly when -object is QAPIfied. This avoids issues with
conversion of bitmaps and also allows validation of the generated JSON
against the QMP schema in the tests.
Since the new approach is triggered by a qemu capability the code
from 'virQEMUBuildObjectCommandlineFromJSON' in util/virqemu.c was moved
to 'qemuBuildObjectCommandlineFromJSON' in qemu/qemu_command.c which has
the virQEMUCaps type.
Some functions needed to be modified to propagate qemuCaps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Set 'objectAddNoWrap' when the capability is present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There's just one caller left. Since qemuBuildMemoryBackendProps is too
complex to be modified for now, just move the adding of 'id' and 'qom'
type directly into the function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Construct the JSON object which is used for object-add without the
'props' wrapper and add the wrapper only in the monitor code.
This simplifies the JSON->commandline generator in the first place and
also prepares for upcoming qemu where 'props' will be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Starting from qemu-6.0 the parameters of -object/object-add are formally
described by the QAPI schema. Additionally this changes the nesting of
the properties as the 'props' nested object will be flattened to the
parent.
We'll need to detect whether qemu switched to this new approach to
generate the objects with proper nesting and also allow testing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The firmwareFeatures member of virDomainOSDef struct is allocated
in virDomainDefParseBootFirmwareOptions() but never freed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The virDomainDefFree() function frees individual members of
virDomainDef struct. The function is already long enough, move
code that handles def->os member into a separate function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Our reallocation APIs already abort on OOM and thus can only return 0.
There's no need to force callers to check the result.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
virQEMUCapsGet checks for qemuCaps itself, no need to do it explicitly.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
In case an async job spans multiple APIs (e.g., incoming migration) the
API that started the job is recorded as the asyncOwnerAPI even though it
is no longer running and the owner thread is updated properly to the one
currently handling the job. Let's also update asyncOwnerAPI to make it
more obvious which is the current (or the most recent) API involved in
the job.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Attempting to set the memlock limit might fail if we're running
in a containerized environment where CAP_SYS_RESOURCE is not
available, and if the limit is already high enough there's no
point in trying to raise it anyway.
https://bugzilla.redhat.com/show_bug.cgi?id=1916346
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Store the current memory locking limit and the desired one
separately, which will help with later changes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we've implemented a fallback for the function that
obtains the information from /proc, there is no reason we would
get a failure unless there's something seriously wrong with the
environment we're running in, in which case we're better off
reporting the issue to the user rather than pretending
everything is fine.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Calling prlimit() requires elevated privileges, specifically
CAP_SYS_RESOURCE, and getrlimit() only works for the current
process which is too limiting for our needs; /proc/$pid/limits,
on the other hand, can be read by any process, so implement
parsing that file as a fallback for when prlimit() fails.
This is useful in containerized environments.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement "<os firmware='efi'>" support for bhyve driver.
As there are not really lot of options, try to find
"BHYVE_UEFI.fd" firmware which is installed by the
sysutils/uefi-edk2-bhyve FreeBSD port.
If not found, just use the first found firmware
in the firmwares directory (which is configurable via
config file).
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the backup job is terminated normally the security label is
restored by the blockjob finishing handler.
If the VM dies or is destroyed that wouldn't happen as the blockjob
handler wouldn't be called.
Restore the security label on disk store where we remember that the job
was running at the point when 'qemuBackupJobTerminate' was called.
Not resetting the security label means that we also leak the xattr
attributes remembering the label which prevents any further use of the
file, which is a problem for block devices.
This also requires that the call to 'qemuBackupJobTerminate' from
'qemuProcessStop' happens only after 'vm->pid' was reset as otherwise
the security subdrivers attempt to enter the process namespace which
fails if the process isn't running any more.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1939082
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemuBackupBegin can take a full backup of the disks (excluding any
operations with bitmaps) without the need to wait for the
blockdev-reopen support in qemu.
Add a check that no checkpoint creation is required and the disk backup
mode isn't VIR_DOMAIN_BACKUP_DISK_BACKUP_MODE_INCREMENTAL.
Call to virDomainBackupAlignDisks is moved earlier as it initializes the
disk backup mode if not present in user config.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming commit will enable full backup support (incremental part
requires blockdev-reopen, which won't happen in qemu for at least
another release).
Add a capability that the 'blockdev-backup' job is supported by qemu
capped, but limited to when qemu supports QEMU_CAPS_BLOCKDEV.
We can also use it in the expression to enable
QEMU_CAPS_INCREMENTAL_BACKUP since it's a pre-requisite too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the firmware auto-selection was introduced it always picked first
usable firmware based on the JSON descriptions on the host. It is
possible to add/remove/change the JSON files but it will always be for
the whole host.
This patch introduces support for configuring the auto-selection per VM
by adding users an option to limit what features they would like to have
available in the firmware.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The original code used a lot of conditions and was not that obvious
when each XML bits are parsed.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With this, XML fails if non-virtio video devices have virtio
options. Previously it didn't raise error.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1922093
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move this function in order to use it in the next patch before
its previous declaration.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, virDomainDeviceInfoParseXML() uses node->children
evaluation which is too verbose. Use XPath evaluation which is
nicer.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Function virDomainDeviceInfoParseXML() will need it soon, because it
will be doing XPath evaluation.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
