Pavel Hrdina [Wed, 10 Nov 2021 14:44:07 +0000 (15:44 +0100)]
qemu_snapshot: revert: always restart QEMU process for running VM
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>
Pavel Hrdina [Wed, 10 Nov 2021 12:55:58 +0000 (13:55 +0100)]
qemu_snapshot: revert: always error out if VM XML is missing
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>
Pavel Hrdina [Fri, 19 Nov 2021 17:01:23 +0000 (18:01 +0100)]
util: fix various ATTRIBUTE_NONNULL calls
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>
qemu_command: Don't validate accelerator when building cmd line
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>
Peter Krempa [Fri, 19 Nov 2021 12:25:00 +0000 (13:25 +0100)]
qemuMonitorJSONBuildChrChardevReconnect: Unify with qemuBuildChrChardevReconnectStr
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>
Peter Krempa [Fri, 19 Nov 2021 12:17:27 +0000 (13:17 +0100)]
qemuMonitorJSONAttachCharDevGetProps: Rename 'backend_type' and 'data'
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>
Michal Privoznik [Wed, 15 Sep 2021 13:59:59 +0000 (15:59 +0200)]
qemu_command: Generate -mem-prealloc in one corner case more
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>
cpu_ppc64.c: remove 'guest' param from ppc64Compute()
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 03fa904c0c0cb2.
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>
Vasiliy Ulyanov [Fri, 19 Nov 2021 12:37:38 +0000 (13:37 +0100)]
qemu: Fix the check of AMD secure guest support
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 3f9c1a4bb841
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>
Peter Krempa [Tue, 16 Nov 2021 13:45:53 +0000 (14:45 +0100)]
qemuDomainPrepareStorageSourceBlockdev: Set default encryption engine also when preparing virStorageSource
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: ab1d46d6128 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 18 Nov 2021 08:23:09 +0000 (09:23 +0100)]
qemuBuildHostdevMediatedDevProps: Format 'ramfb' only when enabled
Before commit 73c352ab8c97d3 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: 73c352ab8c97d3
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>
Peter Krempa [Mon, 15 Nov 2021 15:52:52 +0000 (16:52 +0100)]
qemuxml2argvtest: Fix type for faked chardev backing a TPM
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>
Peter Krempa [Fri, 5 Nov 2021 15:51:22 +0000 (16:51 +0100)]
conf: Properly instantiate virDomainChrSourceDef in virDomainTPMDef
'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>
Peter Krempa [Thu, 14 Oct 2021 13:53:48 +0000 (15:53 +0200)]
qemu: hotplug: Add wrapper for qemuMonitorAttachCharDev
Add a simple wrapper for 'qemuMonitorAttachCharDev' named
'qemuHotplugChardevAttach' which will simplify the moving of the
character device property generator out of the monitor code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
x86Compute() is a static function called only by virCPUx86Compare()
which passes NULL to the 'guest' parameter of x86Compute().
The last caller of x86Compute() that used it with 'guest' != NULL
was an API called 'cpuGuestData'. This API was dropped by commit 03fa904c0c0cb2 a few years ago. Since then all callers of x86Compute()
uses it with 'guest' = NULL.
Removing the 'guest' parameter allow us to remove a good chunk of
logic that isn't being used for awhile.
Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Andrea Bolognani [Mon, 15 Nov 2021 17:13:56 +0000 (18:13 +0100)]
meson: Introduce qemu_datadir option
There is no guarantee that QEMU and libvirt have been configured
with the same prefix.
In particular, Homebrew on macOS will pass a different, private
prefix for each package version and then use symlinks to make
the files for a specific version appear in the usual locations.
This works perfectly fine as long as one package doesn't try to
go poking around another package's data - which is exactly what
libvirt needs to do in order to read and parse the QEMU interop
data.
qemu_datadir can now be explicitly provided to make this and
other uncommon scenarios work. The common scenario, where QEMU
and libvirt both use the same prefix, is unaffected.
https://gitlab.com/libvirt/libvirt/-/issues/168
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 15 Nov 2021 17:57:52 +0000 (18:57 +0100)]
qemu: Set QEMU data location correctly
While datadir must live under prefix, there is no requirement
that its name must necessarily be "share": a different,
arbitrary name could have been provided by the user.
Fixes: 3c876d2428ee3abbb11a50698a9e225cffb72cbc Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 15 Nov 2021 17:16:40 +0000 (18:16 +0100)]
meson: Define qemu_moddir correctly
We can't hardcode /usr here, because the user might have
configured whatever arbitrary prefix.
Everything appeared to be okay because when joining paths
Meson will drop any component that precedes an absolute path
and libdir happens to be absolute, but we should still do
things correctly instead of relying on this.
Fixes: 2ad009eadde27491ff4248f481560953776b2a87 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Tue, 16 Nov 2021 10:02:01 +0000 (11:02 +0100)]
spec: Don't create unnecessary directory
The directory is already created by the build system, so we
don't need to create it explicitly in the spec file; moreover,
the path was incorrect, because it used datadir instead of
localstatedir.
Fixes: 4e041189f85bc1b0f8d5278c0cafdd4aba55beaf Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
tests/qemuxml2*/graphics-spice-timeout: skip CPU model check
Commit 65b0b746b516 changed spice tests to use latest caps. Before this
change, "FLAG_REAL_CAPS" wasn't being set in testQemuInfoInitArgs(). The
absence of this flag triggered the code path inside
testCompareXMLToArgv() that executed testUpdateQEMUCaps(). This function
will update the host CPU via virQEMUCapsUpdateHostCPUModel() into
virQEMUCapsInitHostCPUModel(). In this function,
virQEMUCapsInitCPUModel() would end up updating the hostCPU inside the
qemuCaps (via virQEMUCapsProbeHostCPU()). Before the forementioned
commit, the host CPU was being defaulted to x86_64, vendor Intel, for
the 'graphics-spice-timeout' test that is using the 'pc' machine type
and 'accel=kvm'.
Today, "FLAG_REAL_CAPS" is being set because we're using the latest caps
from x86_64. This means that the whole code path mentioned above is
skipped. qemuCaps are now being loaded via virQEMUCapsLoadCache()
directly. Without the handling being done by testUpdateQEMUCaps(), the
host CPU is being retrieved later on, down below
qemuProcessCreatePretendCmdPrepare() into qemuProcessUpdateGuestCPU().
The latter will attempt to update the domain cpu and executing a
virCPUCompare with the hostCPU and def->cpu.
All this logic ended up causing a failure of the
'graphics-spice-timeout' test in ppc64 and s390x hosts. This test is
being run with KVM acceleration, and the KVM driver for ppc64 and s390x
will return a default x86_64 CPU with vendor "AMD", making
virCPUCompare() fail with the following message:
"QEMU XML-2-ARGV graphics-spice-timeout.x86_64-latest ... libvirt: CPU
Driver error : the CPU is incompatible with host CPU: host CPU vendor does
not match required CPU vendor Intel"
Fix this test by setting cpu check='none' and avoid the virCPUCompare()
that causes the problem for ppc64 and s390x hosts.
Note that this is a build fix. A more adequate fix would be to mock the
getHost() interface of the cpuDriverX86 for non-x86 hosts, allowing
'fullCPU' to be retrieved in qemuProcessUpdateGuestCPU(), and a proper
x86 CPU to be retrieved in the scenario described above.
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Peter Krempa [Tue, 9 Nov 2021 12:29:43 +0000 (13:29 +0100)]
qemuDiskSourceGetProps: Initialize 'ret'
Upcomming patch will convert virJSONValueObjectCreate which didn't check
the value of the passed argument to virJSONValueObjectAdd which will and
this would lead to crashes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 9 Nov 2021 15:28:23 +0000 (16:28 +0100)]
virJSONValueObjectAddVArgs: Allocate new object if passed pointer is NULL
Until now the code would crash if virJSONValueObjectAdd is used without
a valid object. Adding the functionality of allocating it if it's NULL
will allow us to replace all uses of virJSONValueObjectCreate with this
single function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 9 Nov 2021 15:23:01 +0000 (16:23 +0100)]
virJSONValueObjectAddVArgs: Take double pointer
Pass in the double pointer from the wrappers directly to
virJSONValueObjectAddVArgs, which will allow us to directly allocate the
new objects inside the function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
The upcoming QEMU 6.2.0 implements a new event called
DEVICE_UNPLUG_GUEST_ERROR, a new event that reports generic device
unplug errors that were detected by the guest and reported back to QEMU.
This new event is going to be specially useful for pseries guests that
uses newer kernels (must have kernel commit 29c9a2699e71), which is the
case for Fedora 34 at this moment. These guests have the capability of
reporting CPU removal errors back to QEMU which, starting in 6.2.0, will
emit the DEVICE_UNPLUG_GUEST_ERROR event. Libvirt can use this event to
abort the device removal immediately instead of waiting for 'setvcpus'
timeout.
QEMU 6.2.0 is also going to emit DEVICE_UNPLUG_GUEST_ERROR for memory
hotunplug errors, both in pseries and ACPI guests. QEMU 6.1.0 reports
memory removal errors using the MEM_UNPLUG_ERROR event, which is going to
be deprecated by DEVICE_UNPLUG_GUEST_ERROR in 6.2.0. Given that
Libvirt wasn't handling the MEM_UNPLUG_ERROR event we don't need to
worry about it - adding support to DEVICE_UNPLUG_GUEST_ERROR will be
enough to cover all future cases.
This patch adds support to DEVICE_UNPLUG_GUEST_ERROR by adding the
minimal wiring required for Libvirt to be aware of it. The monitor
callback for this event will abort the pending removal operation of the
device reported by the "device" property of the event. Most of the heavy
lifting is already done by existing code that handles
QEMU_DOMAIN_UNPLUGGING_DEVICE_STATUS_GUEST_REJECTED, making our life
easier to abort the pending removal operation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
tests: update QEMU and domain ppc64 capabilities for qemu 6.2
This patch updates domaincapsdata and qemucapabilitiesdata for ppc64
with qemu commit v6.1.0-1714-gc5b2f55981.
Changes in all 'ppc64-latest.ags' files were needed. The changes are
mundane despite the volume. For all 'ppc64-latest.args' files the
changes are:
- removing '-sandbox' command line;
- 'secret' and 'memory-backend-ram' objects are now using qom-type format;
- '-device' is now using qom-type format.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
In a few cases we call a public API, wrapped in an if() statement
with both branches written out explicitly. The error branch jumps
onto cleanup label, while the successful prints out a message.
Right after these ifs there's 'ret = true;' and the cleanup
label. The code is a bit more readable if only the error branch
is kept and printing happens at the same level as setting the ret
variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Kristína Hanicová <khanicov@redhat.com>
Currently, the dommigrate example returns 0 or 1 for success or
failure state, respectively. Except for a few cases where it
forgot to change the @ret variable just before jumping onto the
'cleanup' label. Making the code follow our usual pattern
(initialize @ret to an error value and set it to success value
only at the end) fixes those cases. Also, using EXIT_SUCCESS and
EXIT_FAILURE is more portable (even though on my system they are
just an alias to values the example already uses).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Kristína Hanicová <khanicov@redhat.com>
Michal Privoznik [Wed, 27 Oct 2021 12:41:58 +0000 (14:41 +0200)]
qemuMonitorOpen: Rework domain object refcounting
Similarly to one of previous commits, there's no need to
increment domain object refcounter before unlocking it. Any
number of lock and unlock calls over domain object has no effect
on the refcounter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 27 Oct 2021 11:38:22 +0000 (13:38 +0200)]
qemuAgentOpen: Rework domain object refcounting
Currently, when opening an agent socket the qemuConnectAgent()
increments domain object refcounter and calls qemuAgentOpen()
where the domain object pointer is simply stored inside
_qemuAgent struct. If qemuAgentOpen() fails, then it clears @cb
member only to avoid qemuProcessHandleAgentDestroy() being called
(which decrements the domain object refcounter) and the domain
object refcounter is then decreased explicitly in
qemuConnectAgent().
The same result can be achieved with much cleaner code: increment
the refcounter inside qemuAgentOpen() and drop the dance around
@cb.
Also, the comment in qemuConnectAgent() about holding an extra
reference is not correct. The thread that called
qemuConnectAgent() already holds a reference to the domain
object. No matter how many time the object is locked and unlocked
the reference counter can't be decreased.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 27 Oct 2021 11:38:05 +0000 (13:38 +0200)]
qemu_agent: Rework domain object locking when opening agent
Just like qemuMonitorOpen(), hold the domain object locked
throughout the whole time of qemuConnectAgent() and unlock it
only for a brief time of actual connect() (because this is the
only part that has a potential of blocking).
The reason is that qemuAgentOpen() does access domain object
(well, its privateData) AND also at least one argument (@context)
depends on domain object. Accessing these without the lock is
potentially dangerous.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1845468#c12 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
With this program we do not have to depend on the output of `certtool -i`, which
changed the order of the fields at some point and the newest version is
incompatible with what libvirt expects in tls_allowed_dn_list configuration
option.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
docs: Simplify explanation of tls_allowed_dn_list wildcards
This removes a dead link, the need for users to understand a glib function and a
improper reference to fnmatch (as we only expand asterisks to any string).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This commit doesn't aim to extinguish every VIR_FREE() call, but
only those which were touched by the previous commit. The aim is
to drop cleanup/error labels.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
qemuagenttest: Don't leak virTypedParameter on failure
There are two functions (testQemuAgentOSInfo() and
testQemuAgentTimezone()) which call virTypedParamsFree() only in
successful paths. If an error is met then those parameters would
be leaked. Fix this by placing the virTypedParamsFree() calls on
better place.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
projects / thirdparty / libvirt.git / log
