Use virJSONValueObjectGetArray + virJSONValueArrayToStringList instead
so that the ofvirJSONValueObjectGetStringArray wrapper can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In two instances (qemuMonitorJSONGetStringListProperty,
qemuMonitorJSONGetStringArray) the return value is checked by
qemuMonitorJSONCheckReply and extracted by
virJSONValueObjectGetStringArray.
We can use qemuMonitorJSONGetReply which returns it directly and then
virJSONValueArrayToStringList to convert it without the additional
lookup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using 'virJSONValueObjectHasKey' when we want to access the value
afterwards is wasteful. Fetch the JSON value right away.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Rather than checking that the object has the correct key and then
fetching it again use fetch the array first and then use
virJSONValueArrayToStringList to directly convert it.
Additionally we can avoid the conversion if there are no members
simplifying the surrounding logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'dependencies' field in the return data may be missing in some
cases. Historically 'virJSONValueObjectGetStringArray' didn't report
error in such case, but later refactor (commit 043b50b948 ) added
an error in order to use it in other places too.
Unfortunately this results in the error log being spammed with an
irrelevant error in case when qemuAgentGetDisks is invoked on a VM
running windows.
Replace the use of virJSONValueObjectGetStringArray by fetching the
array first and calling virJSONValueArrayToStringList only when we have
an array.
Fixes: 043b50b948
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2149752
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce virJSONValueArrayToStringList which does only the conversion
from an array to a stringlist.
This will allow refactoring the callers to be more careful in case when
they want to handle the existance of the member in the parent object
differently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use qemuMonitorJSONGetReply and unify the two blocks with the same
condition.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use qemuMonitorJSONGetReply in cases where qemuMonitorJSONCheckReply
is followed by virJSONValueObjectGet*(reply, "return").
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Replace usage of the following pattern with the new helper:
if (qemuMonitorJSONCheckReply(cmd, reply, VIR_JSON_TYPE_ARRAY) < 0)
return -1;
data = virJSONValueObjectGetArray(reply, "return");
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Replace usage of the following pattern with the new helper:
if (qemuMonitorJSONCheckReply(cmd, reply, VIR_JSON_TYPE_OBJECT) < 0)
return -1;
data = virJSONValueObjectGetObject(reply, "return");
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Rather than simply checking that the 'return' field is of the expected
type we can directly return it as the caller is very likely going to use
it. Extract the code into the new function and add a wrapper to preserve
old functionality.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Fix the type for few internal functions. Externally the APIs were
already limiting 'flags' to 'unsigned int'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Don't continue with the historical mistake and fix all internal
functions to use a sane type for flags.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The API itself uses 'unsigned int' so use the same type for the local
variable in virsh.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Historically our migration APIs declare 'unsigned long flags'. Since
it's baked into our API we can't change that but we can avoid
compatibility problems by preemptively refusing the extra range on
certain arches to prevent future surprise.
Modify the macro to verify that value passed inside 'flags' doesn't
exceed the range of 'unsigned int'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The spec file uses both "libvirt" and "%{name}", but in reality the
expanded value of %{name} will never change. Drop the macro in favor
of the explicit and more readable "libvirt".
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Currently translated at 99.2% (10292 of 10368 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/zh_CN/
Co-authored-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Remove %triggerpostun for the daemon package. Upgrades from
libvirt < 1.3.0 are now unlikely.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In one of recent commits I've introduced a new test case to
commandtest. In the test case I'm using poll() to wait for data
on a pipe (the write end is passed to commandhelper). However, on
FreeBSD the POLLIN semantic is a bit different:
POLLIN Data other than high priority data may be read
without blocking.
Well, the pipe is non-blocking, so even if there's no data to be
read the flag is set (and subsequent read() returns 0). On the
other hand, POLLHUP is set too, BUT, if the commandhelper manages
to write everything into the pipe and die right after we'd get
both POLLIN and POLLHUP after the very first time poll() returns.
That's very unfortunate, but okay - we can just check whether
read() returned zero and break from the reading loop.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Instead of using:
if (STRNEQ(a, b)) {
virTestDifference(stderr, a, b);
...
}
we can use:
if (virTestCompareToString(a, b) < ) {
...
}
Generated by the following spatch:
@@
expression a, b;
@@
- if (STRNEQ(a, b)) {
+ if (virTestCompareToString(a, b) < 0) {
...
- virTestDifference(stderr, a, b);
...
}
and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then
in some cases variables passed to STRNEQ() are in reversed order
when compared to virTestCompareToString()).
However, coccinelle failed to recognize the pattern in
testNWFilterEBIPTablesAllTeardown() so I had to fix it manually.
Also, I manually fixed testFormat() in tests/sockettest.c as I
didn't bother writing another spatch rule just for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The virTestDifference() is perfectly capable of handling NULL
arguments. There's no need to wrap arguments in NULLSTR().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Two things are happening here:
1) Call to virTestDifference() is guarded by '!result ||
STRNEQ(result, _)' check. This is suboptimal since we have
STRNEQ_NULLABLE().
2) There are couple of VIR_TEST_DEBUG() printings, which are
useless. If debug is off they don't print anything, and if it
is on, then much more information is printed by subsequent
virTestDifference().
This makes the STRNEQ() + virTestDifference() combo look similar
to the rest of tests and thus can be picked up by spatch later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In the commandtest there is checkoutput() function which checks
the latest log of commandhelper (containing things like cmd line
arguments, env vars, FDs, CWD, etc.) and compares that against
expected output. Well, the way this function implements that is
effectively by open coding virTestCompareToFile() except for the
nice feature that the virTestCompareToFile() has:
VIR_TEST_OUTPUT_REGENERATE.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Introduce a test case which ensures that a daemonized process can
work with virCommandSetSendBuffer() when async IO is enabled.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The virCommandSetSendBuffer() function consumes passed @buffer,
but takes it only as plain pointer. Switch to a double pointer to
make this obvious. This allows us then to drop all
g_steal_pointer() in callers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In test27() the virCommandSetSendBuffer() is used, which expects
unsigned char. Use that type for variables which are passed to
the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Back in v1.0.3-rc1~235 when I was adding virCommandDoAsyncIO(),
the main event loop was used to poll() on the pipe to the child
process. But this was promptly changed to a separate thread
handling I/O in v1.0.3-rc1~127. However, the corresponding
comment to virCommandDoAsyncIO() still documents the original
state.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
When virCommandSetSendBuffer() is used over a virCommand that is
(or will be) daemonized, then the command must have
VIR_EXEC_ASYNC_IO flag set no later than at virCommandRunAsync()
phase so that the thread that's doing IO is spawned and thus
buffers can be sent to the process.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Error message reports that the guest has '0' NUMA nodes
configured when trying to attach a memory device to a guest with
no NUMA nodes. This may be a little misleading because '0' can
also be node's id. A more friendly way is to directly report
that the guest has no NUMA nodes.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2142519
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
QEMU capabilities is the only thing we use from priv so we can just pass
that directly.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When an internal API takes a vm pointer, it's usually just after the
driver argument.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The vm object is used inside qemuMigrationCookieParse based on the flags
passed to qemuMigrationCookieParse and the content of the cookie. The
callers should not just blindly guess and pass NULL if they
(incorrectly) think the vm object is not needed. We should always pass
the vm object unless it does not exist yet.
This fixes a bug when statistics of a completed migration reported
"Unknown" operation instead of "Incoming migration" on the destination
host.
https://bugzilla.redhat.com/show_bug.cgi?id=2137298
Fixes: v8.7.0-79-g0150f7a8c1
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virNodeDeviceGetPCIVPDDynamicCap() function is called from
virNodeDeviceGetPCIDynamicCaps() and therefore has to be a wee
bit more clever about adding VPD capability. Namely, it has to
remove the old one before adding a new one. This is how other
functions called from virNodeDeviceGetPCIDynamicCaps() behave
as well.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2143235
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/
Co-authored-by: Weblate <noreply@weblate.org>
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
As of [1]. libselinux changed the type of context_str() - it now
returns a const string. Follow this change in our code base.
1: dd98fa3227
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Inside of qemuTPMEmulatorBuildCommand() there are two calls to
qemuTPMSetupEncryption() which simply ignore returned error. This
is suboptimal because then we rely on swtpm binary reporting a
generic error (something among invalid command line arguments)
while an error reported by qemuTPMSetupEncryption() is more
specific.
However, since virCommandSetSendBuffer() only sets an error
inside of virCommand structure (the error is then reported in
virCommandRun()), we need to exempt its retval from error
checking. Thus, the signature of qemuTPMSetupEncryption() is
changed a bit so that -1/0 can be returned to indicate error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In commit c43718ef67 I've added a disclaimer that the new stats which
are fetched from qemu and passed directly to the user are not guaranteed
by libvirt. I didn't notice that per-vcpu hypervisor specific stats are
also snuck into the VIR_DOMAIN_STATS_VCPU group along with other
pre-existing stats we do guarantee.
Extend the disclaimer for VIR_DOMAIN_STATS_VCPU too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Mention 'virt-qemu-sev-validate', SGX EPC, vTPM migration, cpu flag
additions and other notable changes in this release.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa