Currently translated at 22.9% (2386 of 10419 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/fi/
Co-authored-by: Jan Kuparinen <copper_fin@hotmail.com>
Signed-off-by: Jan Kuparinen <copper_fin@hotmail.com>
Remove the argument from the function prototypes and the callback
handler.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to the qemu driver if we store the immutable driver pointer in
the VM private data struct we don't have to questionably pass it through
opaque pointers to callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to the qemu driver if we store the immutable driver pointer in
the VM private data struct we don't have to questionably pass it through
opaque pointers to callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The returned value is used to unlock the object, so all callers must
necessarily make use of the returned value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When dealing with fdsets only we don't need to pass the FD first as we
now generate fdset name directly. Also there are no more caveats in
passing multiple FDs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the 'direct' mode was separated and thus we don't have any
possible error case we can stop returning any values and simplify
callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This finishes the separation of the fdset and direct helpers. Remove
'qemuFDPassNewDirect' and all internals which were applicable only in
direct mode.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The callers adding the FDs are validating them regardless so this check
was redundant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unix socket chardevs with FD passing need to use the direct mode so we
need to convert it to use qemuFDPassDirect.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Originally I envisioned a common set of APIs for both FD passing
approaches but it turns out they are not really compatible enough for it
to make sense to use one set of APIs.
As of such introduce a distinct set of APIs for the 'direct' mode, which
will later be used to convert all places that currently use
'qemuFDPassNewDirect' and later clean up the existing APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the internal documentation about qemu threading to the knowledge
base.
The conversion included rstizing of the text document, mainly just
fixing of the headline and enclosing function names and code examples
into code block sections.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The commandline generated from our XML->native convertor is the majority
of cases not usable without libvirt anyways and the situation will not
improve any more.
As of such there's no much utility of avoiding the use of stopped CPUs
flag in such case.
Remove the QEMU_BUILD_COMMAND_LINE_CPUS_RUNNING flag and the associated
logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Now that we store the state of the host FIPS mode setting in the qemu
driver object, we don't need to outsource the logic into
'qemuCheckFips'.
Additionally since we no longer support very old qemu's which would not
yet have --enable-fips we can drop the part of the comment about very
old qemus.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Automatically free the 'vm' temporary domain object and remove the
'cleanup' label and 'ret' helper variable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Improve the debug log inside 'qemuBuildCommandLine' to include the name
from the definition and remove useless data such as the pointer to the
qemuDriver object or qemuCaps.
Additionally remove the non-specific debug statements:
VIR_DEBUG("Building emulator command line");
from the two callers of qemuBuildCommandLine.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Rather than re-query all the time we can cache the state of FIPS of the
host as it will not change during the runtime of the guest.
Introduce a 'hostFips' flag to 'virQEMUDriver' and move the code
checking the state from 'qemuCheckFips' to 'qemuStateInitialize' and
also populate 'hostFips' in qemuxml2argvtest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Introduce 'qemuBuildCommandLineFlags' and use it instead of specific
flag booleans.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We already format a commandline using FD passing for the tap devices so
formatting the 'vhost' file descriptors won't make it any less usable
directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
In the qemu driver certain configs such as disk throttling or CPU
hotplug is configured by interacting with the monitor at the startup
phase of the hypervisor and thus is not part of the "native config".
Add a paragraph into the documentation outlining that the native
configuration might not be completely usable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
In the qemu driver certain configs such as disk throttling or CPU
hotplug is configured by interacting with the monitor at the startup
phase of the hypervisor and thus is not part of the "native config" as
returned by 'virConnectDomainXMLToNative'.
Similarly at least the commandline for qemu contains resources passed
via file descriptors which are obviously not part of the returned
"native config".
Add a paragraph into the documentation outlining that the native
configuration might not be completely usable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Add support for the mode and add the corresponding qemuxml2argv test
case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'absolute' clock offset type has a 'start' attribute which is an
unix epoch timestamp to which the hardware clock is always set at start
of the VM.
This is useful if some VM needs to be kept set to an arbitrary time for
e.g. testing or working around broken software.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The last use of this function was removed in commit 6d161bcc, so the
function is no longer used except as an internal implementation for
virCommandPassFD().
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
commit f9236200 removed the last use of this function, so it can be
dropped.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We have to always store the state of the feature in the
virDomainDef struct, otherwise
<smm state='off'/>
will incorrectly be interpreted as if the <smm> element was not
present.
Fixes: eeb94215b0
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This complements the existing smm=on tests. Looking at the output
files, one can immediately see how this case is currently not being
handled correctly. We're going to fix that in the next commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use DO_TEST_CAPS_LATEST() instead of hardcoding capabilities and
add the xml2xml part, which was missing; finally, rename it to
accomodate the complementary smm=off test that we're about to
introduce.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
None of the callers now uses the slirp fd passing feature, so it can be
removed.
At this point even the VIR_DEBUG doesn't make sense as it would only log
the pointer of 'props'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We don't need 'slirpfdName' and 'slirpfd'. The 'slirp' local can be
removed too as qemuSlirpStart is safe to be called if there's nothing to
do.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Populate the 'slirpfd' qemuFDPass structure inside the private data for
passing the fd to qemu rather than using out-of-band variables.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
No need to ask the callers to call this extra function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'driver' can be taken from the private data of 'vm' and 'slirp' can
be taken from private data of 'net', both of which we need anyways.
Additionally by checking whether slirp needs to be started inside the
function we don't need to do this logic in the callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both callers populate the variable when qemuInterfacePrepareSlirp
returned 1. We can save the hassle in the callers by just doing it right
away.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
