The virDomainTPMVersion enum is declared in domain_conf.h among
with its TypeFromString() and TypeToString() helpers (which are
then implemented in domain_conf.c). However, neither of these
helpers is exposed in libvirt_private.syms which makes it
impossible for other modules to use.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
When we call qemuDomainSetMaxMemLock to reset memory locking limit back
to its original value the domain can already be stopped (for example
after the domain shuts down during migration) in which case it does not
make sense to set any limit. Doing so can even be harmful as we may end
up setting the limit for the daemon itself as the PID is 0.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When resetting private data after stopping QEMU process we should also
reset the original memory locking limit (both normal and pre-migration)
as they are not relevant anymore.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The qemuDomainDefCPUPostParse() does a bit more than filling in
missing info. It also validates CPU cache configuration. Move
that code into qemuValidateDomainDefCpu() where the code fits
better.
And since I need to fix indentation of existing code in
qemuValidateDomainDefCpu(), I'm taking this opportunity and move
error messages onto single line. Interestingly, this uncovers a
bug we have in sc_prohibit_diagnostic_without_format syntax-check
rule, because previously a virReportError() with a message
spawned over three lines was not caught but not it is. But
trying to understand that regex is a job for another time.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Directly check the return value of 'connect'. Unfortunately we can't
remove it as we have to undo auto-closing of the socket on success.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
All callers now pass false for 'retry' we are guaranteed to have a
monitor socket present. This means that the retry code can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In 'qemuProcessQMPLaunch' qemu is very specifically launched using it's
internal '-daemonize' flag (see comment in the function) to ensure that
the monitor socket is ready and opened prior to attempting the monitor
connection.
This means we don't have to retry the connection to the monitor in
qemuMonitorOpen as the socket will be already there.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The 'timeout' argument is used by 'qemuMonitorOpenUnix' only when the
'retry' argument is true. The callers of 'qemuMonitorOpen' only pass '0'
for timeout when they call it with 'retry' true and use other values
when 'retry' is false and thus ignored.
This means we can remove the argument and simply have it set to the
default value of QEMU_DEFAULT_MONITOR_WAIT.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Both callers pass 'false' as the argument via a variable which is not
modified. Remove the argument and pass 'false' directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Since functions virQEMUCapsFillDomainFeatureSEVCaps() and
virQEMUCapsSEVInfoCopy() essentially do the same thing it does
not make sense to have the code duplicated. This patch replaces
the relevant code in the first function with the function call to
the second one.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
With glibc 2.36, sys/mount.h and linux/mount.h conflict:
https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E
lxc_container.c imports sys/mount.h and linux/fs.h, which pulls in
linux/mount.h.
linux/fs.h isn't required here though. glibc sys/mount.h has had
MS_MOVE since 2.12 in 2010
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This patch removes and replaces virCHDomainObjResetJob() with
general virDomainObjResetJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
This patch removes and replaces virLXCDomainObjResetJob() with
general virDomainObjResetJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
This patch removes and replaces libxlDomainObjResetJob() with
general virDomainObjResetJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
This patch moves qemuDomainObjResetJob() as
virDomainObjResetJob() into hypervisor in order to be used by
other hypervisors as well.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In virtpm.h there are two functions exposed for querying swtpm
and swtpm_setup capabilities: virTPMSwtpmCapsGet() and
virTPMSwtpmSetupCapsGet(), respectively. The capabilities we are
interested in are defined in two separate enums
(virTPMSwtpmFeature and virTPMSwtpmSetupFeature), but these
functions accept capability as an unsigned int rather than their
respective enum. While this makes sense for
virTPMBinaryGetCaps(), which is a module internal helper that
both exposed functions call, there's no need for the functions
themselves to accept unsigned int.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
When no TPM version is provided in the input XML we may default
to version 2.0 (see qemuDomainTPMDefPostParse()). However,
<active_pcr_banks/> are parsed iff a version 2.0 was specified.
This means that this piece of information might be lost.
It's better to parse everything we've been given and then
validate that the configuration is valid.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2084046
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
After previous cleanup, the qemuDomainDefTPMsPostParse() function
does nothing more than validates TPM devices. Therefore, it
should live in qemu_validate.c instead of qemu_domain.c. Move it
there and rename to reflect the fact that the function is doing
validation instead of PostParsing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In the qemuDomainDefPostParse() we aim to fill in top level
values, which require overall view of domain, or those parts of
configuration that are not a device in domain XML (e.g. vCPUs).
However, inside of qemuDomainDefTPMsPostParse(), which is called
from aforementioned function, we do two tings:
1) fill in missing info (TPM version), and
2) validate TPM definition.
Now, if 1) is moved into qemuDomainTPMDefPostParse() (the device
post parse callback), then 2) can be moved into validation step.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When parsing a TPM device plenty of virXMLPropString() +
enum2int() combos are used. These can be replaced with
virXMLPropEnum().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The _virDomainTPMDef structure has 'version' member, which is a
bit misplaced. It's only emulator type of TPM that can have a
version, even our documentation says so:
``version``
The ``version`` attribute indicates the version of the TPM. This attribute
only works with the ``emulator`` backend. The following versions are
supported:
Therefore, move the member into that part of union that's
covering emulated TPM devices.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In previous commit the VIR_DOMAIN_TPM_VERSION_DEFAULT value was
made just an alias to value of 0. And since all newly allocated
memory is zeroed out (due to use of g_new0()), the def->version
inside of virDomainTPMDefParseXML() is also 0 and thus there is
no need to set it explicitly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When "default" version of TPM was provided, our parses accepts it
happily even though the value is forbidden by our RNG and not
documented as accepted value. This is because of < 0 vs <= 0
comparison of virDomainTPMModelTypeFromString() retval.
Make the parser error out explicitly in this case. Users can
always chose to not specify the attribute in which case we pick a
sane default (in qemuDomainDefTPMsPostParse()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When "default" model of a TPM was provided, our parses accepts it
happily even though the value is forbidden by our RNG and not
documented as accepted value. This is because of < 0 vs <= 0
comparison of virDomainTPMModelTypeFromString() retval.
Make the parser error out explicitly in this case. Users can
always chose to not specify the attribute in which case we pick a
sane default (in qemuDomainTPMDefPostParse()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There's no need to skip over ENOENT error in
qemuCgroupAllowDevicesPaths(). The path must exists when
qemuCgroupAllowDevicePath() is called because of virFileExists()
check done right above.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuBuildMachineCommandLine() function is needlessly long.
Separate out parts that generate memory related arguments into
qemuAppendDomainMemoryMachineParams(). Unfortunately, expected
outputs for some qemuxml2argvdata cases needed to be updated
because the order in which arguments are generated is changed.
But there's no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuBuildMachineCommandLine() function is needlessly long.
Separate out parts that generate arguments based on
domainDef->features[] into
qemuAppendDomainFeaturesMachineParam(). Unfortunately, expected
outputs for some qemuxml2argvdata cases needed to be updated
because the order in which features are generated is changed. But
there's no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Almost all of memory models we currently support allow setting
virDomainMemoryDef::targetNode so that the memory module is
associated with given guest NUMA node. And we do have a check
whether the requested node is within bounds, but it's executed
only when building QEMU's cmd line. Move it into validation
phase.
While this commit is moving the validation to a place that does
not validate all the possible code paths, it's okay, because only
the explicit memory device has user-configurable target node
which could break the assumption.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, virJSONValueObjectHasKey() can return one of three
values:
-1 if passed object type is not VIR_JSON_TYPE_OBJECT,
0 if the key is not present, and finally
1 if the key is present.
But, neither of callers is interested in the -1 case. In fact,
some callers call this function treating -1 and 1 cases the same.
Therefore, make the function return just true/false and fix few
callers that explicitly checked for == 1 case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In my recent comnmit v8.5.0-188-gc47f1abb81 I accidentally moved
qemuMigrationParamsResetTLS after qemuDomainObjEnterMonitorAsync not
noticing qemuMigrationParamsResetTLS will try to enter the monitor
again. The second call will time out and return with a domain object
locked. But we're still in monitor section and the object should be
unlocked which means qemuDomainObjExitMonitor will deadlock trying to
lock it again.
Fixes: c47f1abb81
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This call to qemuMigrationSrcIsAllowedHostdev() (which does a
hardcoded fail of the migration if there is any PCI or mdev hostdev
device in the domain) while doing the destination side of migration
prep was found once the call to that same function was removed from
the source side migration prep (commit 25883cd5).
According to jdenemar, for the V2 migration protocol, prep of the
destination is the first step, so this *was* the proper place to do
the check, but for V3 migration this is in a way redundant (since we
will have already done the check on the source side (updated by
25883cd5 to query QEMU rather than do a hardcoded fail)).
Of course it's possible that the source could support migration of a
particular VFIO device, but the destination doesn't. But the current
check on the destination side is worthless even in that case, since it
is just *always* failing rather than querying QEMU; and QEMU can't be
queried at the point where the destination check is happening, since
it isn't yet running.
Anyway QEMU should complain when it's started if it's going to fail,
so removing this check should just move the failure to happen a bit
later. So the best solution to this problem is to simply remove the
hardcoded check/fail from qemuMigrationDstPrepareFresh() and rely on
QEMU to fail if it needs to.
Fixes: 25883cd5f0
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Commit v8.4.0-287-gd4d3bb8130 tried to make sure the original
pre-migration memory locking limit is restored at the end of migration,
but it missed the case when libvirt daemon is restarted during
migration which needs to be aborted on reconnect.
And if this was not enough, I forgot to actually save the status XML
after setting the field in priv (in the commit mentioned above and also
in v8.4.0-291-gd375993ab3).
https://bugzilla.redhat.com/show_bug.cgi?id=2107424
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The function would fail to release the job in case
qemuMigrationSrcIsAllowed failed.
Fixes v8.5.0-157-g69e0e33873
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When the <loader stateless='yes'/> attribute is set, the QEMU driver
needs to do three things
- Avoid looking for an NVRAM template
- Avoid auto-populating an <nvram/> path
- Find firmware descriptors with mode=stateless instead of mode=split
Note, the first thing happens automatically when we solve the second
thing.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Normally when an UEFI firmware is marked as read-only, an associated
NVRAM file will be created. Some builds of UEFI firmware, however, wish
to remain stateless and so will be read-only, but never have any NVRAM
file. To represent this concept a 'stateless' tristate bool attribute
is introduced on the <loader/> element.
There are rather a large number of permutations to consider.
With default firmware selection
* <os/>
=> Historic default, no change
* <os>
<loader stateless='yes'/>
</os>
=> Explicit version of historic default, no change
* <os>
<loader stateless='no'/>
</os>
=> Invalid, bios is always stateless
With manual legacy BIOS selection
* <os>
<loader>/path/to/seabios</loader>
...
</os>
=> Historic default, no change
* <os>
<loader stateless='yes'>/path/to/seabios</loader>
...
</os>
=> Explicit version of historic default, no change
* <os>
<loader stateless='no'>/path/to/seabios</loader>
...
</os>
=> Invalid, bios is always stateless
With manual UEFI selection
* <os>
<loader type='pflash'>/path/to/edk2</loader>
...
</os>
=> Historic default, no change
* <os>
<loader type='pflash' stateless='yes'>/path/to/edk2</loader>
...
</os>
=> Skip auto-filling NVRAM / template
* <os>
<loader type='pflash' stateless='no'>/path/to/edk2</loader>
...
</os>
=> Explicit version of historic default, no change
With automatic firmware selection
* <os firmware='bios'/>
=> Historic default, no change
* <os firmware='bios'>
<loader stateless='yes'/>
</os>
=> Explicit version of historic default, no change
* <os firmware='bios'>
<loader stateless='no'/>
</os>
=> Invalid, bios is always stateless
* <os firmware='uefi'/>
=> Historic default, no change
* <os firmware='uefi'>
<loader stateless='yes'/>
</os>
=> Skip auto-filling NVRAM / template
* <os firmware='uefi'>
<loader stateless='no'/>
</os>
=> Explicit version of historic default, no change
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Because qemuMigrationParamsReset used to call qemuMigrationParamsApply
for resetting migration capabilities and parameters, it did not work
well since commit v5.1.0-83-ga1dec315c9 which only allowed capabilities
to be set from an async job. However, when reconnecting to running
domains after daemon restart we do not have an async job. Thus the
capabilities were not properly reset in case the daemon was restarted
during an ongoing migration. We need to avoid calling
qemuMigrationParamsApply to make sure both parameters and capabilities
can be reset by a normal job.
https://bugzilla.redhat.com/show_bug.cgi?id=2107892
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
qemuMigrationParamsApply restricts when capabilities can be set, but
this is not useful in all cases. Let's create new helpers for setting
migration capabilities and parameters which can be reused in more places
without the restriction.
https://bugzilla.redhat.com/show_bug.cgi?id=2107892
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We keep original values of migration parameters so that we can restore
them at the end of migration to make sure later migration does not use
some random values. However, this does not really work when libvirt
daemon is restarted on the source host because we failed to explicitly
save the status XML after getting the migration parameters from QEMU.
Actually it might work if the status XML is written later for some other
reason such as domain state change, but that's not how it should work.
https://bugzilla.redhat.com/show_bug.cgi?id=2107892
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The VIR_ENUM_IMPL macros directly above them list one string per line.
Use the same also for qemuMonitorMigrationStatus and
qemuMonitorVMStatus.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It's no longer possible for libvirt to connect over the ssh transport
from RHEL 9 to RHEL 5. This is because SHA1 signatures have been
effectively banned in RHEL 9 at the openssl level. They are required
to check the RHEL 5 host key. Note this is a separate issue from
openssh requiring additional configuration in order to connect to
older servers.
Connecting from a RHEL 9 client to RHEL 5 server:
$ cat ~/.ssh/config
Host 192.168.0.91
KexAlgorithms +diffie-hellman-group14-sha1
MACs +hmac-sha1
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
$ virsh -c 'qemu+ssh://root@192.168.0.91/system' list
error: failed to connect to the hypervisor
error: Cannot recv data: ssh_dispatch_run_fatal: Connection to 192.168.0.91 port 22: error in libcrypto: Connection reset by peer
"error in libcrypto: Connection reset by peer" is the characteristic
error of openssl having been modified to disable SHA1 by default.
(You will not see this on non-RHEL-derived distros.)
You could enable the legacy crypto policy which downgrades security on
the entire host, but a more fine-grained way to do this is to create
an alternate openssl configuration file that enables the "forbidden"
signatures. However this requires passing the OPENSSL_CONF
environment variable through to ssh to specify the alternate
configuration. Libvirt filters out this environment variable, but
this commit allows it through. With this commit:
$ cat /var/tmp/openssl.cnf
.include /etc/ssl/openssl.cnf
[openssl_init]
alg_section = evp_properties
[evp_properties]
rh-allow-sha1-signatures = yes
$ OPENSSL_CONF=/var/tmp/openssl.cnf ./run virsh -c 'qemu+ssh://root@192.168.0.91/system' list
root@192.168.0.91's password:
Id Name State
--------------------
Essentially my argument here is that OPENSSL_CONF is sufficiently
similar in nature to KRB5CCNAME, SSH* and XAUTHORITY that we should
permit it to be passed through.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2062360
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Note that we can only do this for intel-iommu and virtio-iommu,
which are configured using -device; smmuv3 is configured using
a machine type property, so there's no room on the command line
for an alias in that case.
https://bugzilla.redhat.com/show_bug.cgi?id=2108483
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When hotplugging a chardev, Libvirt opens corresponding
file/binds to a socket/does whatever necessary to obtain an FD
that is later passed to QEMU. However, due to wrong placement of
the function that does all of this
(qemuProcessPrepareHostBackendChardevHotplug()) it may happen
that a file is set seclabel on, only to be unlink()-ed and
created again (the former is done by
qemuSecuritySetChardevLabel(), the latter by aforementioned
function). The unlink()-ing is done for UNIX sockets with
mode='bind' and happens inside qemuOpenChrChardevUNIXSocket().
However, these steps can be swapped simply.
Fixes: ad81aa8ad0
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
When hotplugging a chardev, Libvirt opens corresponding
file/binds to a socket/does whatever necessary to obtain an FD
that is later passed to QEMU. However, if something fails after
the FDs were transferred to QEMU and before chardev is actually
added via monitor, these FDs are never closed in QEMU. This is
rather suboptimal.
Fixes: 15bdced9b3
Fixes: ad81aa8ad0
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Pattern of using switch instead of a long if else construction is
used everywhere, so I used it here as well to make the code more
consistent (and remove that else after return). I also included
all the values from the enum.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The else branches are redundant because the execution will never
reach them if the conditions in the previous 'if' branches are
true.
I think this looks cleaner and is more readable, because having
'else' branch indicates that no return / break / goto is in the
previous branch and the function can reach it.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This patch rewrites conditions to make the code easier to read and less
nested.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit 6262752460 added the acquiring of a job, but it is not always
VIR_ASYNC_JOB_MIGRATION_OUT, so the code fails when doing save or anything else.
Correct the async job by passing it from the caller as another parameter.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add a new flag VIR_LXC_PROCESS_CLEANUP_AUTODESTROY to
virLXCProcessCleanupFlags for skipping removal of the autodestroy
callback so that fake reboot of the container doesn't need to fetch the
connection and re-register it.
Since virLXCProcessReboot is defined before virLXCProcessCleanupFlags,
this patch also moves the flag enum typedef to the beginning of the
file.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Use automatic unlocking of the 'vm' object, so that we can return early
when no autostart is needed and avoid passing of the 'driver' object
which is already present in 'vm's' private data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
The connection object is not needed when autostarting containers so we
can remove the machinery for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Remove the pointless 'cleanup' section and 'ret' variable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
The function doesn't really need the connect object for anything besides
registering the autodestroy callback for it. If we merge it certain
callers can be simplified.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Add possibility for the caller to set the flags for the call to
'virLXCProcessCleanup'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
libvirt currently will block migration for any vfio-assigned device
unless it is a network device that is associated with a virtio-net
failover device (ie. if the hostdev object has a teaming->type ==
VIR_DOMAIN_NET_TEAMING_TYPE_TRANSIENT).
In the future there will be other vfio devices that can be migrated,
so we don't want to rely on this hardcoded block. QEMU 6.0+ will
anyway inform us of any devices that will block migration (as a part
of qemuDomainGetMigrationBlockers()), so we only need to do the
hardcoded check in the case of old QEMU that can't provide that
information.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The new code that queries QEMU about migration blockers was put at the
top of qemuMigrationSrcIsAllowed(), but that function can also be
called in the case of offline migration (ie when the domain is
inactive / QEMU isn't running). This check should have been put inside
the "if (!(flags & VIR_MIGRATE_OFFLINE))" conditional, so let's move
it there.
Fixes: 156e99f686
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The code is run with an async job and thus needs to make sure a nested
job is acquired before entering the monitor.
While touching the code in qemuMigrationSrcIsAllowed I also fixed the
grammar which was accidentally broken by v8.5.0-140-g2103807e33.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch removes and replaces virCHDomainObjInitJob() with
general virDomainObjInitJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch removes and replaces virLXCDomainObjInitJob() with
general virDomainObjInitJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch removes and replaces libxlDomainObjInitJob() with
general virDomainObjInitJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch moves qemuDomainObjInitJob() as virDomainObjInitJob()
into hypervisor in order to be used by other drivers as well.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have qemuCgroupAllowDevicePath() which sets up devices
controller for just one path. And if we have more paths we have
to call it in a loop. So far, we have just one such place, but
soon we'll have another one (for SGX memory). Separate the loop
into its own function so that it can be reused.
And while at it, move setting the default set of devices as the
first thing, right after all devices are disallowed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Inside of the qemuSetupDevicesCgroup() there's @deviceACL
variable, which points to a string list of devices that are
allowed in devices controller by default. This list can either
come from qemu.conf (cfg->cgroupDeviceACL) or from a builtin
@defaultDeviceACL. However, a multiline ternary operator is used
when setting the variable which is against our coding style.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
vDPA devices will be migratable soon, so we shouldn't unconditionally
block migration of any domain with a vDPA device. Instead, we should
rely on QEMU to make the decision when that info is available from the
query-migrate QMP command (QEMU versions too old to have that info in
the results of query-migrate don't support migration of vDPA devices,
so in that case we will continue to unconditionally block migration).
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Since QEMU 6.0, if QEMU knows that a migration would fail,
'query-migrate' will return an array of error strings describing the
migration blockers. This can be used to check whether there are any
devices/conditions blocking migration.
This patch adds a call to this query at the top of
qemuMigrationSrcIsAllowed().
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Since QEMU 6.0, if migration is blocked for some reason,
'query-migrate' will return an array of error strings describing the
migration blockers. This can be used to check whether there are any
devices, or other conditions, that would cause migration to fail.
This patch adds a function that sends this query via a QMP command and
returns the resulting array of reasons. qemuMigrationSrcIsAllowed()
will be able to use the new function to ask QEMU for migration
blockers, instead of the hardcoded guesses that libvirt currently has.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
since qemu 6.0, if migration is blocked for some reason, 'query-migrate'
will return an array of error strings describing the migration blockers.
This can be used to check whether there are any devices blocking
migration, etc.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
QEMU supports hotplug of a cdrom device with USB or SCSI bus. Just
unblock these devices in qemuDomainAttachDeviceDiskLiveInternal() and
qemuDomainDetachPrepDisk().
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/261
Signed-off-by: minglei.liu <minglei.liu@smartx.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
According to a9fe9569ab, the <acpi index='NNN'/> is only for PCI
devices. Remove the ref acpi from devices channel, smartcard, tpm,
redirdev, panic, hub because none of them has PCI address. And add the
ref acpi to iommu device.
Fixes: a9fe9569ab
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch prevents nesting of if conditions and makes the code
cleaner.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch alters members of virDomainObjPrivateJobCallbacks to
make the code more consistent.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch moves qemuDomainJobObj into hypervisor/ as generalized
virDomainJobObj along with generalized private job callbacks as
virDomainObjPrivateJobCallbacks.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch removes variable 'async', which is used only once, and
replaces it with direct comparison with an enum member.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This was not causing any problems because all cases below were empty,
but in order to avoid future misbehavior, add a break to this case.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There's no need to use virBufferAddStr() for literal strings
without any newline character as it's more expensive than
virBufferAddLit().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
When formatting qemuCaps XML, the <cpudata/> element is
misaligned. This is because it contains multiple lines and
virBufferAsprintf() does not expect that. Switch to
virBufferAddStr() which does.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
The G_GNUC_NO_INLINE macro will eventually be marked as
deprecated [1] and we are recommended to use G_NO_INLINE instead.
Do the switch now, rather than waiting for compile time warning
to occur.
1: 15cd0f0461
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Currently, we require glib-2.56.0 at minimum (because of RHEL-8)
but we use G_GNUC_NO_INLINE which was introduced in 2.58.0. While
we provide an implementation for older versions, where the macro
does not exists, it's a bit more tricky than that. Since we
define GLIB_VERSION_MAX_ALLOWED we would get a compile time error
when trying to use something too new, except for G_GNUC_NO_INLINE
which was intentionally not marked as
GLIB_AVAILABLE_MACRO_IN_2_58. But this is about to change with
glib-2.73.2 (which contains commit [1]).
At the same time, we can't just bump glib and thus we have to
provide an alternative implementation without the version
annotation.
1: a6f8fe071e
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
These wrapper functions were used to adapt the virObjectUnref() function
signature for different callbacks. But in commit 0d184072, the
virObjectUnref() function was changed to return a void instead of a
bool, so these adapters are no longer necessary.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The getters/setters for individual properties of migration
speed/downtime/cache size are unused once we switched to setting them
purely via migration parameters. Remove the unused helpers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'xbzrle-cache-size' parameter was added in qemu-2.11 thus all
supported qemu versions now use the new code path.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'downtime-limit' field of 'migrate-set-parameters' was introduced in
qemu-2.8, thus all qemu versions supported by libvirt use the new code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'max-bandwidth' field was added as argument of
'migrate-set-parameters' in qemu-2.8, thus all qemu version supported by
libvirt already use the new code path.
This patch assumes the presence and removes the legacy code paths.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU offers two attributes for handling reset requests of an USB
host device: guest-reset and guest-resets-all. When combined they
act as follows:
1) guest-reset=false
The guest is not allowed to reset the physical USB device.
2) guest-reset=true,guest-resets-all=false
The guest is allowed to reset the device when it is not yet
initialized (aka no USB bus address assigned). Usually this results
in one guest reset being allowed. This is the default behavior.
3) guest-reset=true,guest-resets-all=true
The guest is allowed to reset the device as it pleases.
Now, there's a clear 1:1 mapping with our representation of
guestReset, so generating cmd line is trivial.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we have a capability, validate that the QEMU we are
talking to has everything we need for guestReset.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We will need two attributes of usb-host device to set:
guest-reset and guest-resets-all. The former was introduced in
QEMU v4.0.0-rc0~56^2 and the other in v4.2.0-rc1~9^2. Hence,
track the latter only as it's only starting from that commit when
QEMU has both attributes.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some USB devices have a buggy firmware that either crashes on
device reset, or make the device unusable in some other way.
Fortunately, QEMU offers a way to skip device reset either
completely, or if device is not initialized yet. Expose this
ability to users under:
<hostdev mode='subsystem' type='usb'>
<source guestReset='off'/>
</hostdev>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It was always possible to modify the inactive XML, because
VIR_DOMAIN_AFFECT_CURRENT (= 0) is accepted implicitly. But now
that the logic when changing both config and live XMLs is more
robust we can accept VIR_DOMAIN_AFFECT_CONFIG flag too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are three APIs that allow changing IOThreads:
virDomainAddIOThread()
virDomainDelIOThread()
virDomainSetIOThreadParams()
In case of QEMU driver these are handled by
qemuDomainChgIOThread() which attempts to be versatile enough to
work on both inactive and live domain definitions at the same
time. However, it's a bit clumsy - when a change to live
definition succeeds but fails in inactive definition then there's
no rollback. And somewhat rightfully so - changes to live
definition are in general harder to roll back. Therefore, do what
we do elsewhere (qemuDomainAttachDeviceLiveAndConfig(),
qemuDomainDetachDeviceAliasLiveAndConfig(), ...):
1) do the change to inactive XML first,
2) in fact, do the change to a copy of inactive XML,
3) swap inactive XML and its copy only after everything
succeeded.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When formatting IOThreads (in virDomainDefIOThreadsFormat()), we
may only output the number of IOThreads, or the full list of IOThreads too:
<iothreads>4</iothreads>
<iothreadids>
<iothread id='1' thread_pool_max='10'/>
<iothread id='2' thread_pool_min='2' thread_pool_max='10'/>
<iothread id='3'/>
<iothread id='4'/>
</iothreadids>
Now, the deciding factor here is whether those individual
IOThreads were so called 'autofill-ed' or user provided. Well, we
need to take another factor in: if an IOThread has pool size
limit set, then we ought to format the full list.
But how can we get into a situation when a thread is autofilled
(i.e. not provided by user in the XML) and yet it has pool size
limit set? virDomainSetIOThreadParams() is the answer.
Sure, we could also unset the autofill flag whenever a pool size
limit is being set. But this approach allows us to not format
anything if the limits are reset (we don't lose the autofill
information).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The <defaultiothread/> element is formatted inside
virDomainDefaultIOThreadDefFormat() which is called only from
virDomainDefIOThreadsFormat() (so that IOThread related stuff is
formatted calling one function). However, when there are no
<iothreadids/> defined (or only autoallocated ones are present),
then the outer formatting function exits early never calling the
<defaultiothread/> formatter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We accept TPM version in the domain XML. However, supported
version depends on the host (swtpm_setup binary) and thus it may
be tricky for users (or mgmt applications) chose a version.
Introduce machinery for reporting supported version in domain
capabilities.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These new capabilities will be used only to track whether
swtpm_setup is capable of TPM-1.2 and/or TPM-2.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
'virtproxyd' doesn't have the '--listen' parameter and it's enough just
to enable the corresponding option in the config.
The config file is generic for all the daemons and we just omit/adjust
some sections. Adding a separate mechanism to omit the note about the
'--listen' parameter would be overkill so mention explicitly that it's
required only for libvirtd and not virtproxyd.
The section is omitted for other daemons.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2094641
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When virDomainSetIOThreadParams() API is called, well its QEMU
impl: qemuDomainSetIOThreadParams() then typed params are parsed
by qemuDomainIOThreadParseParams() into this
qemuMonitorIOThreadInfo struct. In the struct we have a <int,
bool> pair for every IOThread attribute we can tune through
monitor. The struct is then passed to
qemuMonitorJSONSetIOThread() which looks at the bool and if set
then the corresponding attribute is set to given value. Each
attribute is thus changed in a separate call. While this works
for attributes independent of each other ("poll-max-ns",
"poll-grow", "poll-shrink"), it does not always work for the
other attributes ("thread-pool-min" and "thread-pool-max").
The limitation here is that the lower boundary (minimum) has to
be lower (or equal to) the upper boundary (maximum) at all times.
This means, that in some cases we might need to set attributes in
reversed order to meet the constraint.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/339
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Use of the admin APIs to modify logging temporarily has a rather serious
deficiency when the daemon whose config is being changed is using
auto-shutdown (default with socket-activated deployments) as the
configuration is discarded if there is no client or VM/other object
blocking auto shutdown.
This API allows users to disable/postpone shutdown timeout so that the
configuration doesn't change under their hands.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Modify the code so that calling 'virNetDaemonAutoShutdown' will update
the auto shutdown timeout also for running daemons.
This involves changing the logic when to do the update of the timer so
that it can be called from both when the daemon is not yet runnign and
when doing a live update.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce 'virNetDaemonShutdownTimerRegister' and
'virNetDaemonShutdownTimerUpdate' to aggregate the code to deal with the
auto-shutdown timer.
The code is also placed so that it can be called from
'virNetDaemonAutoShutdown' which involved the move of
'virNetDaemonAutoShutdownTimer'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Our coding style suggests 80 chars per line with error messages
being exception (for easier git-grep). Apply this exception onto
the newly created domain_postparse.c file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The domain post parse functions currently live in domain_conf.c
which thus grows always larger. Mimic what we've done for the
validation code and move the post parse code into a separate
file: domain_postparse.c.
I've started by moving every function with PostParse in its name
into the new file and then compile hunting for helper functions
only to move them as well.
In the end, I've moved virDomainDefPostParse symbol in
libvirt_private.syms into a new section. And while
virDomainDeviceDefPostParseOne() is made 'public' in
domain_postparse.h too, I'm not exporting it because it has no
caller outside src/conf/ and it's unlikely it ever will.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainDefPostParseDeviceIteratorData struct is exported in
domain_conf.h because it's used in both domain_conf.c and
domain_validate.c. However, the latter usage is not warranted,
it's just a shortcut so that we don't have to introduce a similar
struct just for domain_validate.c. Well, do the extra step and
introduce a separate structure for domain_validate.c. This allows
us to move post parse code later on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For a qcow2 storage volume with luks encryption created by qemu-img, its
dumped storage vol XML has no secret element in encryption:
<volume type='file'>
...
<encryption format='luks'>
</encryption>
...
</volume>
That will cause a failure in rng validation. Fix that validation failure.
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In my previous commit I've introduced virDomainIOMMUDefValidate()
function with a switch() statement. However, two cases in it,
though empty, were not terminated with a break statement which
made compiler complain.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Per v8.3.0-rc1~199 it's only a virtio IOMMU that can have
<address/>. The rest (Intel and SMMUv3) are system devices and
thus have no address associated with them. However, this
assumption is never checked for.
Fixes: b0eb1e193f
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two places where the @model member of
_virDomainIOMMUDef struct is typecasted to virDomainIOMMUModel
which is completely unnecessary because the struct already
defines the member of that type.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Treat the 'protocolVer' field as a string so that e.g. '4.1' can be
used. Forbid only ',' in the string as it's a separator of arguments for
mount options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
No sane firmware build will fail this check, but just to be on
the safe side let's check anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, a firmware configuration such as
<os firmware='efi'>
<firmware>
<feature enabled='yes' name='enrolled-keys'/>
</firmware>
</os>
will correctly pick a firmware that implements the Secure Boot
feature and initialize the NVRAM file so that it contains the
keys necessary to enforce the signing requirements. However, the
lack of a
<loader secure='yes'/>
element makes it possible for pflash writes to happen outside
of SMM mode. This means that the authenticated UEFI variables
where the keys are stored could potentially be overwritten by
malicious code running in the guest, thus making it possible to
circumvent Secure Boot.
To prevent that from happening, automatically turn on the
loader.secure feature whenever a firmware that implements Secure
Boot is chosen by the firmware autoselection logic. This is
identical to the way we already automatically enable SMM in such
a scenario.
Note that, while this is technically a guest-visible change, it
will not affect migration of existings VMs and will not prevent
legitimate guest code from running.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Regardless of whether firmware autoselection is in use, we
still want to parse the list of requested features. Doing this
will allow us to produce better error messages.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Generally speaking, when firmware autoselection is in use we
don't want any information to be provided manually. There are
two exceptions:
* we still want the path to the NVRAM file to be customizable;
* using <loader secure='yes'/> was how you would ask for a
firmware that implements the Secure Boot feature in the
original approach to firmware autoselection, so we want to
keep that working.
Anything else should result in a descriptive error.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This makes it explicit that there are two possible scenarios
(whether or not firmware autoselection is in use) and will make
upcoming changes cleaner to implement.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently we're simply ignoring some elements and attributes,
such as the loader path, when firmware autoselection is enabled
because we know we're not going to use them.
This makes sense, but has the unfortunate consequence of
confusing users who experience part of their configuration
simply going away for no apparent reason.
A more user-friendly approach is to produce meaningful error
messages in those scenarios. As a first step towards that goal,
stop conditionally parsing information.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This combination doesn't make sense and so the firmware
autoselection logic will not be able to find a suitable firmware,
but it's more user-friendly to report a detailed error upfront.
Note that this check would ideally happen in the validate phase,
but if we moved it there we would no longer be able to
automatically enable secure-boot when enrolled-keys=yes. Since
the combination never resulted in a working configuration, the
chances of this causing real-world VMs to disappear are
extremely low.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are currently no failure scenarios for the function, but
we're about to add one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The latter doesn't make sense without the former, so make that
visible in the XML.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the lack of a <loader> element results in the <nvram>
element being completely ignored, but this is unnecessarily
limiting: even when firmware autoselection is in use, it should
be possible for the user to specify a custom path for the NVRAM
file.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This makes the function more consistent with
virDomainLoaderDefParseXML() by preferring the virXMLProp
class of functions to XPath access.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We're going to start passing multiple nodes to the function in
a moment, so we need a more specific name.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
All the data in the <nvram> element ends up in the same struct
as that coming from the <loader> element, so it makes sense to
have a single entry point for parsing an XML document into a
virDomainLoaderDef instance.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It belongs to virDomainLoaderDefParseXMLNvram(), where the other
parts of the <nvram> element are handled.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the 'type' attribute is present we'd end up overwriting
this value via virDomainStorageSourceParse(). Moving this
assignment makes the current code clearer and will also help
with upcoming changes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The previous name was identical, modulo the case, to the
completely unrelated virDomainNVRAMDefParseXML().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Pure code movement, needed to prepare for upcoming changes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This supports sockets created by libvirt and passed by FD using the
same method as in security_dac.c.
Signed-off-by: David Michael <david@bigbadwolfsecurity.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
According to [1]:
Prior to GnuTLS 3.6.0 for the ephemeral or anonymous
Diffie-Hellman (DH) TLS ciphersuites the application was
required to generate or provide DH parameters. That is no
longer necessary as GnuTLS utilizes DH parameters and
negotiation from [RFC7919].
This allows us to:
a) drop the code that's setting DH params,
b) drop @dhParams member from _virNetTLSContext struct. and
c) drop gnutls_dh_params_generate2() mock.
1: https://www.gnutls.org/manual/html_node/Parameter-generation.html
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When resuming post-copy migration users may want to limit the bandwidth
used by the migration and use a value that is different from the one
specified when the migration was originally started.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/333
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
So the we can apply selected migration parameters even when resuming
post-copy migration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We will need to annotate individual parameters a bit more than just
noting their type. Let's introduce qemuMigrationParamInfo replacing
simple qemuMigrationParamTypes with an array of structs.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The flags will later be used to determine which parameters should
actually be applied.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
My original commit v8.4.0-288-gf01fc4d119 accidentally forgot to fix
both instances of the same problem. While it fixed the destination side
of migration, the source one remained broken.
However, that commit was also wrong in saying the issue could have
caused unlimited memory locking to be allowed for QEMU when RDMA
migration was used. It could not, because the code would refuse to even
think about starting RDMA migration if hard_limit was not set. But
avoiding the "mem.hard_limit > 0" check is useful anyway.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduced in v8.4.0-rc1~183 but the first real problem
introduced in v8.4.0-rc1~170, there's a
qemuBuildInterfaceConnect() call inside of
qemuDomainAttachNetDevice(). If the former fails, then the
function is immediately returned from instead of jumping onto the
cleanup label. This is crucial, because at this point the domain
definition contains 'borrowed' net definition, which is then
freed, since an error was met. The domain definition is then left
with a dangling pointer which leads to all sorts of different
crashes.
Fixes: 29d022b1eb
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2102009
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
An explicit limit would be more user friendly. Add the limit to error message.
Before this commit:
```
error: requested size must be smaller than or equal to @size
```
Now:
```
error: requested size must be smaller than or equal to @size (8388608KiB)
```
Signed-off-by: Liu Yiding <liuyd.fnst@fujitsu.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add <interleave> to allow the subproperties to be specified in any
order.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Our documentation says RDMA migration requires hard_limit to be set so
that we know how big memory locking limit should be set for the domain
during migration. But since commit v1.2.13-71-gcf521fc8ba (which changed
the default hard_limit value from 0 to
VIR_DOMAIN_MEMORY_PARAM_UNLIMITED) we were actually setting memlock
limit to unlimited if hard_limit was not set.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For RDMA migration we update memory locking limit, but never set it back
once migration finishes (on the destination host) or aborts (on the
source host).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This helper will not try to set the limit if it is already big enough,
which may be useful when libvirt daemon is running in a containerized
environment and is not allowed to change memory locking limit.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuDomainAdjustMaxMemLock combined computing the desired limit with
applying it. This patch separates the code to apply a memory locking
limit to a new qemuDomainSetMaxMemLock helper for better reusability.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For all file formats, the length of the size field is assumed
and hardcoded to be 8 bytes.
Fix the length for the ploop format - since we specify the offset,
we read 8 bytes of the length, not 0.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Evaluate the XPath as a boolean, instead of trying to get a node
out of it.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use VIR_AUTOCLOSE for the remaining file descriptor that uses
manual cleanup and remove the label.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Use g_autofree for the two strings still using manual cleanup
and remove the pointless cleanup label.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Convert all the cases where we can unconditionally free
the virURI at the end of scope.
In libxlDomainMigrationDstPrepare, uri is only filled
if uri_in was present, so moving the virURIFree out of
the condition is safe.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The result of the <= 0 comparison was assigned to 'rc', rendering the
if (rc == 0) condition dead code.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When domain startup fails, domain cleanup calls
libxlNetworkUnwindDevices, which calls virGetConnectNetwork, which
is a top level API entry point, which resets the initial saved error,
leading to clients seeing:
error: An error occurred, but the cause is unknown
This preserves the error around the entire teardown process, similar
to what is done in the qemu driver.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Replace tpm->type and tpm->model qemuCaps validation with the
similar logic in domcaps.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The qemu `tpm-tis` device is an ISA device, so only really applicable
to x86 archs. For all non-x86 archs we should use `tpm-tis-device`
This fixes tpm-tis usage on armv7l and riscv
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Checking against qemu capabilities should be enough here
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/329
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When firewalld is restarted or has its rules reloaded, we trigger a
reload of the nwfilter driver. This is done directly in the main
event loop thread which is a bad idea.
In a previous commit we fixed a actual deadlock problem with the
virStateReload API, when triggered from SIGHUP:
commit 33c6eb9689
Author: Jim Fehlig <jfehlig@suse.com>
Date: Thu Mar 8 15:04:48 2018 -0700
libvirtd: fix potential deadlock when reloading
The same deadlock problem previously existed with the firewalld reload
trigger, however, today it is not quite so series. The QEMU driver uses
a private event thread for each VM, so the particular deadlock would
not occur. None the less during the time the filters are reloading all
use of the event loop is blocked, which prevents APIs being serviced.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Internally we already collect x86 host family + model + stepping
numeric values. This exposed them in capabilities CPU output.
Example:
$ sudo virsh capabilities | grep -A1 -B1 signature
<microcode version='240'/>
<signature family='6' model='94' stepping='3'/>
<counter name='tsc' frequency='3408010000' scaling='no'/>
Users need to know these values to calculate an expected.
SEV-ES/SEV-SNP launch measurement.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We explicitly check whether the value is YES or NO, which makes
it unnecessary to make sure it's not ABSENT beforehand.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Even when the os.loader element is absent, we still have to
validate that the user is not attempting to use firmware
autoselection with a driver that doesn't implement the feature.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The feature was implemented in commits b4e34d1083 and
9bb6e4e739 but the corresponding feature flag was not set in
the driver, so other parts of of libvirt wouldn't be able to
know about it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an element to configure the thread pool size:
...
<binary>
<thread_pool size='16'/>
</binary>
...
https://bugzilla.redhat.com/show_bug.cgi?id=2072905
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The check was historically done only for _TYPE_VOLUME disks, but
refactors to allow _TYPE_VOLUME disks in the backing chain caused a
regression where we'd reject startupPolicy also for _TYPE_BLOCK disks
which historically worked well.
Fix it by using the 'virDomainDiskDefValidateStartupPolicy' helper and
use it only when the top level image is a _TYPE_VOLUME as in other cases
it was already validated. This also allows _TYPE_BLOCK volumes to use
startup policy.
Fixes: 37f01262ee
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2095758
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our startup policy checkers work only for local paths, so disk sources
such as NVMe, or vhost-user can't be used with startup policy.
Unfortunately the validation did not catch these cases. Fix it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the code into 'virDomainDiskDefValidateStartupPolicy' which will be
later reused in the qemu driver.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove linebreak and mention the attribute name. Also prepare the error
messages for future by substituting the type of offending access.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refactor the function to use modern XML formatting machinery.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
This patch introduces the logic to format and parse remote NVRAM.
Update NVRAM element schema, and docs for supporting network backed
NVRAM. NVRAM backed over network would give the flexibility to start
the VM on any host without having to worry about where to get the latest
nvram image.
<nvram type='network'>
<source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/0'>
<host name='example.com' port='6000'/>
</source>
</nvram>
or
<nvram type='file'>
<source file='/var/lib/libvirt/nvram/guest_VARS.fd'/>
</nvram>
In the qemu driver we will support the new definition only with qemu's
supporting -blockdev.
Signed-off-by: Prerna Saxena <prerna.saxena@nutanix.com>
Signed-off-by: Florian Schmidt <flosch@nutanix.com>
Signed-off-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Introduce virDomainLoaderDefFormatNvram and extract the code to it so
that it's self-contained in upcoming patches adding more complex logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Prepare for network backed nvram by refusing the reset of nvram on boot
and don't check whether it exists. We will not support filling it from a
template.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Setup all fields for use with -blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
We don't really use it besides when starting up the VM so when
reconnecting this step is totally pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Use the designated helpers for virStorageSource instead using the
file-based ones with a check.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Since we now have a full virStorageSource for storing the nvram path we
don't need the extra dance of transferring the data into the 'pflash1'
variable which was an intermediary solution to use -blockdev.
For now we keep it functionally identical to the previous impl.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Currently, libvirt allows only local filepaths to specify the location
of the 'nvram' image. Changing it to virStorageSource type will allow
supporting remote storage for nvram.
Signed-off-by: Prerna Saxena <prerna.saxena@nutanix.com>
Signed-off-by: Florian Schmidt <flosch@nutanix.com>
Signed-off-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Extract the internals of qemuDomainPrepareStorageSourceBlockdev into
qemuDomainPrepareStorageSourceBlockdevNodename so that we can reuse it
when instantiating the virStorageSource for pflash backing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tested-by: Rohit Kumar <rohit.kumar3@nutanix.com>
This is a partial revert of 87a43a907f
The change to use g_clear_pointer() in more places was accidentally
applied to cases involving vir_g_source_unref().
In some cases, the ordering of g_source_destroy() and
vir_g_source_unref() was reversed, which resulted in the source being
marked as destroyed, after it is already unreferenced. This
use-after-free case might work in many cases, but with versions of
glib older than 2.64.0 it may defer unref to run within the main
thread to avoid a race condition, which creates a large distance
between the g_source_unref() and g_source_destroy().
In some cases, the call to vir_g_source_unref() was replaced with a
second call to g_source_destroy(), leading to a memory leak or worse.
In our experience, the symptoms were that use of libvirt-python became
slower over time, with OpenStack nova-compute initially taking around
one second to periodically query the host PCI devices, and within an
hour it was taking over a minute to complete the same operation, until
it is was eventually running this query back-to-back, resulting in the
nova-compute process consuming 100% of one CPU thread, losing its
RabbitMQ connection frequently, and showing up as down to the control
plane.
Signed-off-by: Mark Mielke <mark.mielke@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
When creating a TAP interface we can end up with multiple FDs,
each representing one queue. However, these FDs must be
relabelled as they are then passed to QEMU. In case of
qemuBuildInterfaceConnect() we allocate the array for the FDs and
then let function corresponding to the <interface/> type to fill
the array with FDs. When any of the functions meets an error,
it's also responsible for closing previously opened FDs. However,
the functions take a shortcut: iterate through each member of the
array and close it (if it's non-negative). This assumes that the
array is initialized to negative values, which use to be the case
before rewrite in v8.4.0-rc1~170 but after it it's no longer the
case. Subsequently, "random" FDs are closed (okay, not that
random since the array is allocated via g_new0(), but hey - FD 0
is still valid FD and might be valuable, actually).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2075383#c18
Fixes: 7a38d3946b
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For some types of SRIOV interfaces we create a temporary file
where the state of the interface is saved before we start
modifying it. The file is used then to restore the original
configuration when the interface is no longer associated with any
guest. For writing the file virFileWriteStr() is used. However,
it's given wrong argument: the last argument is supposed to be
mode to create the file with but virNetDevSaveNetConfig() passes
open(2) flags (O_CREAT|O_TRUNC|O_WRONLY). We need the file to be
writable and readable by root only (0600). Therefore, pass that
mode instead of gibberish.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Commit v7.1.0-136-g6a6d6bb520 refactored virProcessSetMaxMemLock by
moving its part into a new virProcessSetLimit, but lost "return -1" on
error.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Since the main-loop and iothread classes are derived from the
same class (EventLoopBaseClass) we don't need new capability and
can use QEMU_CAPS_IOTHREAD_THREAD_POOL_MAX directly to check
whether QEMU's capable of setting defaultiothread pool size.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
As of v7.0.0-877-g70ac26b9e5 QEMU exposes its default event loop
for devices with no IOThread assigned as an QMP object. In the
very next commit (v7.0.0-878-g71ad4713cc) it was extended for
thread-pool-min and thread-pool-max attributes. Expose them under
new <defaultiothread/> element.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Introduced in previous commit, QEMU driver needs to be taught how
to set VIR_DOMAIN_IOTHREAD_THREAD_POOL_MIN and
VIR_DOMAIN_IOTHREAD_THREAD_POOL_MAX parameters on given IOThread.
Fortunately, this is fairly trivial to do and since these two
parameters are exposed in domain XML too the update of inactive
XML can be wired up too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that we have a capability that reflects whether QEMU is
capable of setting iothread pool size, let's introduce a
validator check to make sure users are not trying to use this
feature with QEMU that doesn't support it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This capability reflects whether QEMU allows setting
thread-pool-min and thread-pool-max attributes on iothread
object. Since both attributes were introduced in the same commit
(v7.0.0-878-g71ad4713cc) and can't exist independently of each
other we can stick with one capability covering both of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
At least in case of QEMU an IOThread is actually a pool of
threads (see iothread_set_aio_context_params() in QEMU's code
base). As such, it can have minimal and maximal number of worker
threads. Allow setting them in domain XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
So far, iothread configuration structure (virDomainIOThreadIDDef)
is allocated by plain g_new0(). This is perfectly okay because
all members of the struct default to value 0 anyway. But soon
this is going to change. Therefore, replace those g_new0() with a
function so that the default value can be set consistently in one
place.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Formatting iothreads is currently open coded inside of
virDomainDefFormatInternalSetRootName(). While this works, it
makes the function needlessly long, especially if the formatting
code will expand in near future. Therefore, move it into a
separate function. At the same time, make
virDomainDefIothreadShouldFormat() accept const domain definition
so that the new function can also accept const domain definition.
Formatters shouldn't need to change definition.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In virDomainIOThreadIDDefArrayInit() the variable @iothrid is
used only inside a loop but is declared for whole function. Bring
the variable into the loop so that it's obvious that the variable
is not used elsewhere.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Using g_autoptr() for @iothrid variable inside
virDomainDefParseIOThreads() allows us to drop explicit call to
virDomainIOThreadIDDefFree() in one case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For easier attribute parsing we have virXMLProp*() family of
functions. These accept flags through which a caller can pose
some conditions onto the attribute value, for instance:
VIR_XML_PROP_NONZERO when the attribute may not be zero, etc.
What we are missing is VIR_XML_PROP_NONNEGATIVE when the
attribute value may be non-negative. Obviously, this flag makes
sense only for some members of the virXMLProp*() family.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
They were constructed from two separate strings using "%s: %s", which
is ugly and does not work well with translations.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When a domain has a guest agent channel enabled and the agent is running
in the guest, we will get VSERPORT_CHANGE event on a destination host as
soon as we start vCPUs there. This is not an issue for normal migration,
but post-copy migration will remain running after we started vCPUs on
the destination. If it runs for more than 30s, the VSERPORT_CHANGE event
handler will fail to get a job and log the following error message:
Timed out during operation: cannot acquire state change lock (held
by monitor=remoteDispatchDomainMigrateFinish3Params)
and of course we will think the guest agent is not connected and thus
all APIs talking to it will fail. Until the agent or libvirt daemon is
restarted.
Luckily we only need to update the channel state (to mark it as
connected) and connect to the agent neither of which conflicts with
migration. Thus we can safely enable processing this event during
migration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This is a special job for operations that need to modify domain state
during an active migration. The modification must not affect any state
that could conflict with the migration code. This is useful mainly for
event handlers that need to be processed during migration and which
could otherwise time out on acquiring a normal MODIFY job.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The original virDomainAbortJob did not support flags.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since all parts of post-copy recovery have been implemented now, it's
time to enable the corresponding flag.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
