Now that qemu fixed device unplug when JSON syntax is used with -device
we can re-enable the feature.
Since the old capability string representation is condemned by
suggesting filtering it as a workaround we must introduce a new string.
To achieve this the original capability position is renamed to
X_QEMU_CAPS_DEVICE_JSON_BROKEN_HOTPLUG and a new position with the
original name QEMU_CAPS_DEVICE_JSON is introduced to prevent us having
to change the rest of the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When -device is configured via JSON a bug [1] is triggered in qemu were
the DEVICE_DELETED event for the removal of the device frontend is no
longer delivered to libvirt. Without the DEVICE_DELETED event we don't
remove the corresponding entries in the VM XML.
Until qemu will be fixed we must stop using the JSON syntax for -device.
This patch removes the detection of the capability. The capability is
used only during startup of a fresh VM so we don't need to consider any
compaitibility steps for existing VMs.
For users who wish to use 'libvirt-7.9' and 'libvirt-7.10' with
'qemu-6.2' there are two possible workarounds:
- filter out the 'device.json' qemu capability '/etc/libvirt/qemu.conf':
capability_filters = [ "device.json" ]
- filter out the 'device.json' qemu capability via qemu namespace XML:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
[...]
<qemu:capabilities>
<qemu:del capability='device.json'/>
</qemu:capabilities>
</domain>
We must never again use the same capability name as we are now
instructing users to filter it as a workaround so once qemu is fixed
we'll need to pick a new capability value for it.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2036669
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2035237
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
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>
'-audiodev' as a modern implementation based on QAPI already takes JSON
as the argument. Convert our code to use it directly.
The declaration of the QAPI types can be found in
'qemu.git/qapi/audio.json'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting with QEMU-6.2 started accepting a JSON object as argument for
'-device' which will also become the only syntax considered stable by
qemu in the future.
Since libvirt was recently converted to generate the properties via JSON
to begin wit we can start using it on the commandline as well, by simply
enabling the QEMU_CAPS_DEVICE_JSON capability, which we do by probing
for the 'json-cli' feature flag of 'device_add'.
Normally a change which changes a commandline output should be happening
only after the impacted real-caps test files are forked in the version
preceding the change, but in this case it's not necessary as the logic
for generating the device properties stays identical and we just change
the output format (avoid conversion). Additionally we still have a lot
of tests validating the conversion to the old commandline options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The mocked path in the test suite is not in sync with what libvirtd
generates.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The commit adding the vhost-user-fs device forgot to format
the device's alias on the command line.
Thankfully it was not needed yet because virtiofs migration
is not yet supported, but it will be needed in the future
to allow hot(un)plug.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
virCommandToString has the possibility to return an already wrapped
string with better format than what we get from the test wrapper script.
The main advantage is that arguments for an option are always on the
same line which makes it more easy to see what changed in a diff and
prevents re-wrapping of the line if a wrapping point moves over the
threshold.
Additionally the used output is the same we have in the VM log file when
a VM is starting.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Base the detection on the presence of the 'secret' qom-type entry, which
isn't conditionally compiled in qemu.
All caps-based test now switch to using JSON for -object.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The -audiodev argument is replacing the QEMU_AUDIO_DRV env variable (and
its relations).
Sadly we still have to use the SDL_AUDIODRIVER env variable because that
wasn't mapped into QAPI schema.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU has long accepted many different values for boolean properties, but
set accepted has been different depending on which QEMU parser you hit.
The on|off values were supported by all QEMU parsers. The yes|no, y|n,
true|false values were only partially supported:
https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg01012.html
Thus we should standardize on on|off everywhere since that is most
widely supported in QEMU.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The preferred syntax for boolean options is to set the value "on" or
"off". QEMU 7.1.0 will deprecate the short format we currently use.
The long format has been supported with -chardev since at least 1.5.3,
so we don't need to check for it.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In 88957116c9 I've switched to -machine memory-backend=ID and
-object memory-backend-* because QEMU is obsoleting -mem-path
and -mem-prealloc. However, what I did not foresee was that using
-machine memory-backend in combination with -numa is not allowed
in QEMU. This was reported upstream and fortunately not released
yet.
The problem is that if domain has NUMA nodes then we will
generate memory-backend-* objects for NUMA nodes (because if QEMU
is new enough to expose default RAM ID it also supports -numa
memdev=) and adding non-NUMA memory backend is wrong.
Reported-by: Masayoshi Mizuma <msys.mizuma@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
So far, Libvirt configures memory-backend-* for memory hotplug,
possibly NUMA nodes and in a few other cases. This patch
switches to constructing the memory-backend-* command line for
all cases. To keep ability to migrate guests a little hack is
used: the ID of the object is set to the one that QEMU uses
internally anyways. These IDs are stable (first started to appear
somewhere around v0.13.0-rc0~96) and can't change.
In fact, this patch does exactly what QEMU does internally. The
reason for moving the logic into Libvirt is that QEMU wants to
deprecate the old style of specifying memory.
So far, only x84_64 test cases are changed, because tests for
other architectures use older capabilities, which still lack the
QEMU_CAPS_MACHINE_MEMORY_BACKEND capability and they don't report
the RAM ID.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1836043
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Initially introduced in v3.10.0-rc1~172.
When generating a path for memory-backend-file or -mem-path, qemu
driver will use the following pattern:
$memoryBackingDir/libvirt/qemu/$id-$shortName
where $memoryBackingDir defaults to /var/lib/libvirt/qemu/ram but
can be overridden in qemu.conf. Anyway, the "/libvirt/qemu/" part
looks redundant, because it's already contained in the default,
or creates unnecessary nesting if overridden in qemu.conf.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Format the 'vhost-user-fs' device on the QEMU command line.
This device provides shared file system access using the FUSE protocol
carried over virtio.
The actual file server is implemented in an external vhost-user-fs device
backend process.
https://bugzilla.redhat.com/show_bug.cgi?id=1694166
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Tested-by: Andrea Bolognani <abologna@redhat.com>
