Recent cleanup of snapshot revert code made these function unused.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It does not need a tty to work, it opens its controlling terminal for user
interaction and with this patch even crazy things like this work:
echo 'list --name' | virsh -q >/dev/null
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Trying to connect once without a polkit agent will generate an error on the
server side which seems too rough given it only serves the purpose of the client
(virsh in this case) to figure out that an agent is needed. Thankfully we can
just try running the agent. It does not break anything as we are running it
with `--fallback`, which makes sure it does not replace an existing agent in
case there is one already registered.
The second piece of code trying to start the polkit text agent is kept in order
to _really_ try out starting the agent (and error out when failing to do so)
just in case the agent was not available the first time it was ran. Even though
it should not happen it avoids a very rare race condition and really does not
add much complexity.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1945501
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With this function we can decide whether to try running the polkit text agent
only if it is available, removing a potential needless error saying that the
agent binary does not exist, which is useful especially when running the agent
before knowing whether it is going to be needed.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatic "Ptr " -> " *" also wreaked havoc in comments. Fix it and while at it
reword the sentence so it is clear that the object is newly allocated.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It only redundantly reflects whether pkagent != NULL.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Recently, FreeBSD has got sched_get/setaffinity(3) implementations and
the sched.h header as well [1]. To make these routines visible,
users have to define _WITH_CPU_SET_T.
This breaks current detection. Specifically, meson sees the
sched_getaffinity() symbol and defines WITH_SCHED_GETAFFINITY. This
define unlocks Linux implementation of virProcessSetAffinity() and other
functions, which fails to build on FreeBSD because cpu_set_t is not
visible as _WITH_CPU_SET_T is not defined.
For now, change detection to the following:
- Instead of checking sched_getaffinity(), check if 'cpu_set_t' is
available through sched.h
- Explicitly check the sched.h header instead of assuming its presence
if WITH_SCHED_SETSCHEDULER is defined
1:
https://cgit.freebsd.org/src/commit/?id=43736b71dd051212d5c55be9fa21c45993017fbbhttps://cgit.freebsd.org/src/commit/?id=160b4b922b6021848b6b48afc894d16b879b7af2https://cgit.freebsd.org/src/commit/?id=90fa9705d5cd29cf11c5dc7319299788dec2546a
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
We've changed the behavior of this API that from now on it will always
restart the VM process and we are no longer able to revert to snapshots
created by libvirt older then 0.9.5.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This will always happen so there is no need to error out and require
usage of FORCE flag.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that we always emulate restarting the VM process events are emitted
differently so we need to update the code and the comment as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that we always emulate VM process stop we can drop the unused code
and simply the logic.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reflect the same change in test driver as in QEMU driver because the
compatibility check code isn't perfect.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When active snapshot is reverted we stop CPUs in order to load the
snapshot but we never start the CPUs again.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We should have this check even if FORCE flag is used because later we
unconditionally copy the `snap->def->dom` and error out if there is no
copy created. The test driver will always save the VM XML when creating
new snapshot.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This will always happen so there is no need to error out and require
usage of FORCE flag.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that we always restart the QEMU process events are emitted
differently so we need to update the code and the comment as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that we always restart QEMU process the loadvm code is unused and
can be dropped.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Our compatibility check code isn't complete and there are cases where it
fails to detect incompatible configuration and the revert fails. In
addition future support for external snapshot will always require
restarting the QEMU process.
To unify the behavior drop the compatibility check code and always
restart the QEMU process.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The support to revert snapshots was introduced in libvirt 0.8.0 but
saving the whole VM XML was implemented later in libvirt 0.9.5.
That is more then 10 years ago so we can safely assume that nobody will
try reverting to snapshot created by that old libvirt. In the unlikely
scenario where someone would actually did it we would simply error out.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Git bisect took me to commit where incorrect usage of ATTRIBUTE_NONNULL
was introduced and caused coverity scan to fail. This patch fixes the
issue where the index starts from 1 and not 0 and two other different
cases.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We currently use -machine accel=XXX which is just a syntax sugar
for -accel XXX. The former doesn't allow specifying arguments for
accelerator, because all arguments passed to -machine are
treated as arguments of machine itself.
The -accel argument was introduced in QEMU commit
v2.9.0-rc0~70^2~19 and since our minimum required version is
newer (2.11.0) we can safely assume its existence and use it
without any capability.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/233
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The domain accelerator was validated in qemuValidateDomainDef()
which calls virQEMUCapsIsVirtTypeSupported() which reports proper
error if QEMU is not capable of KVM/TCG. There is no point in
doing the validation again when building command line.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Use 'virJSONValueObjectAdd' instead of the step-by-step manual JSON
object building.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When formatting the commandline we explicitly set the reconnect timeout
to 0 when it's disabled even when that's the default. Do the same in
the monitor/hotplug code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename 'data' to 'backendData' so that it's more clear what the object
represents and 'backend_type' to 'backendType' to go with the common
camel case notation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In some cases we have a label that contains nothing but a return
statement. The amount of such labels rises as we use automagic
cleanup. Anyway, such labels are pointless and can be dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
When guest has NUMA nodes and QEMU is new enough to report
default RAM ID then ideally we would use -numa memdev= combined
with memory-backend-* combo becasue -mem-path/-mem-prealloc/-numa
mem are deprecated. Well, there is one problem - the .memdev=
attribute is machine type dependent (just look at arguments of
virQEMUCapsGetMachineNumaMemSupported()) and to ensure backwards
compatibility we prefer -numa mem= over -numa memdev=.
But there was one corner case when -mem-prealloc was requested
but not generated on the cmd line. It all starts with
qemuBuildMemCommandLine() which generates just '-m XXX' and
because it sees defaultRAMid and guest NUMA nodes greater than
zero it does nothing more.
Then, qemuBuildNumaCommandLine() sees that -numa mem= is still
supported for given machine type and nothing else set
@needBackend thus qemuBuildMemPathStr() is called which output
-mem-prealloc only in a few cases assuming it was outputted
earlier.
Reported-by: Jing Qi <jinqi@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This test shows a bug we have: even though the XML says:
<allocation mode='immediate'/>
there is no -mem-prealloc nor .prealloc=yes anywhere on the cmd
line. This will be fixed in the next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Create extra g_autofree strings and use them in an adequate scope to
eliminate the need for VIR_FREE() calls and the 'cleanup' label.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
ppc64Compute() is used only once, by virCPUppc64Compare(), which
doesn't use the 'guest' parameter. It was last used by an API
called 'cpuGuestData' that was dropped by commit 03fa904c0c.
Removing the 'guest' parameter will not only remove unused code from
ppc64Compute() but also remove the ppc64MakeCPUData() entirely.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
'str' is no longer being used and the 'cleanup' label can be removed
together with the 'ret' variable.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Create a new helper to remove the arch validation logic from the
body of virQEMUCapsLoadCache().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Create a new helper to remove the emulator validation logic from the
body of virQEMUCapsLoadCache().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Create a new helper to remove the GIC parse logic from the body of
virQEMUCapsLoadCache().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Create a new helper to remove the parse capabilities flag logic from the
body of virQEMUCapsLoadCache().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
The content of /sys/module/kvm_amd/parameters/sev may vary depending on
the kernel version. Check also for 'Y' and 'y' in addition to '1' to
cover several possible variants. The fix is similar to the one
introduced in commit 3f9c1a4bb8
Signed-off-by: Vasiliy Ulyanov <vulyanov@suse.de>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 114e3b4232 added matching by
aliases for interfaces with same MAC address.
( https://bugzilla.redhat.com/show_bug.cgi?id=1926190 )
However, unless the domain is using user aliases (prefixed ua-),
there are no aliases in the persistent definition.
Only match by MAC/PCI/other addresses in that case, to fix update-device
with --persistent flag (AFFECT_LIVE | AFFECT_CONFIG).
https://bugzilla.redhat.com/show_bug.cgi?id=2024098
Fixes: 114e3b4232
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Originally the default encryption engine is populated in the disk
post-parse callback code. This works for disks but for any additional
images introduced either via the block copy API or via the backup API we
don't populate the default.
In case when the backup or block copy is requested on an encrypted image
this would then lead to an error:
error: internal error: Unexpected enum value 0 for virStorageEncryptionEngine
This patch adds another point where we populate the default which is
when setting up a virStorageSource for actual usage.
We keep the original setting in the post-parse callback as that's the
only point that is recorded in the XML file after definition.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2023674
Fixes: ab1d46d612
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a test case where 'ramfb' is explicitly disabled for a mediated
device to prevent regressing again.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Before commit 73c352ab8c which converted the hostdev commandline
formatter to JSON the 'ramfb' property was formatted only if it was
enabled.
The main reason for that is that enabling 'ramfb' switches the device
model to 'vfio-pci-nohotplug' which actually has the property, while
'vfio-pci' (used when 'ramfb' is disabled or absent) doesn't have it.
Restore the logic to format 'ramfb' only when it's enabled and add a
comment that it's deliberate.
Fixes: 73c352ab8c
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2024435
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test filled the chardev type to VIR_DOMAIN_CHR_TYPE_FILE and thus
set the 'data.emulator.source->data.file.path' pointer, but the
commandline formatter is unconditionally expecting VIR_DOMAIN_CHR_TYPE_UNIX
and thus reading 'data.emulator.source->data.nix.path'. Since it's an
union it happened to land in the correct place. Fix the faked data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'virDomainChrSourceDef' contains private data so 'virDomainChrSourceDefNew'
must be used to allocate it. 'virDomainTPMDef' was using it directly
which won't work with the chardev helper functions.
Convert it to a pointer to properly allocate private data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's referenced only once and it's a shortcut to the chardev source thus
can be used directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than returning a different error code if the device address needs
to be released pass in the 'need_release' flag via a pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is already getting 'virDomainObj' which has already the
driver pointer present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch to automatic memory clearing for the two virJSONValues and remove
the 'cleanup' label and 'ret' variable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
