qemuDomainMakeCPUMigratable() strips the features that a CPU model marks
as added (in src/cpu_map/x86_*.xml) from the migratable definition unless
the user requested them explicitly. This keeps a custom CPU migratable to
an older destination libvirt whose copy of the model does not know those
features yet.
A host-model CPU gains nothing from this and is actively harmed by it. By
the time it reaches this function host-model has already been expanded
into an explicit custom model that is exactly what we ask QEMU for on the
source, and host-model is not guaranteed to migrate to an older libvirt
in the first place. Stripping the added features only narrows the guest
CPU silently on the destination.
Every Intel model from Westmere through Sapphire Rapids marks
vmx-exit-load-perf-global-ctrl and vmx-entry-load-perf-global-ctrl as
added. These control the LOAD_IA32_PERF_GLOBAL_CTRL allowed-1 bits of the
MSR_IA32_VMX_{EXIT,ENTRY}_CTLS MSRs, which modern QEMU only advertises
when the features are present on the -cpu command line. After a host-model
live migration the destination QEMU is started without them, so a nested
guest observes different VMX capability MSRs than it did before the
migration. A guest that snapshots those MSRs at kvm_intel module load and
validates every newly onlined CPU against the snapshot -- Linux does
exactly that -- then refuses to bring up a vCPU hot-plugged after the
migration:
kvm_intel: Inconsistent VMCS config on CPU N
kvm: enabling virtualization on CPUN failed
smpboot: CPU N is now offline
and the guest agent's online attempt returns -EIO.
Treat a host-model CPU's features as explicitly requested by building the
keep list from the already expanded definition rather than from origCPU.
Custom CPUs are unaffected, so their migration compatibility with older
destinations is preserved.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
For socket activation to work our systemd unit files use the following
pattern:
[virtlogd.socket] <----(After)--- [virtlogd.service]
[virtqemud.socket] <----(After)--- [virtqemud.service]
Now the qemu daemon also wants to use the services provided by those
daemons so we have dependency between the two too:
[virtlogd.socket] <----(After)--- [virtlogd.service]
^
+-------------(After+Requires)-------+
|
[virtqemud.socket] <----(After)--- [virtqemud.service]
Now on startup everything is fine, because with socket activation, when
'virtqemud.service' wants to use 'virtlogd' services the socket is
already up due to the dependency+ordering and opening a connection will
cause 'virtlogd.service' to be socket-activated.
On shutdown though there's no transitive 'After' ordering between
'virtqemud.service' and 'virtlogd.service' and thus nothing explicitly
telling systemd that if virtlogd was started. In fact systemd is free to
translate it that 'virtlogd' and 'virtqemud' need to be stopped before
stopping 'virtlogd.socket'.
To illustrate what happens consider the following scenario:
A host is running a VM under virtqemud. 'virtqemud' is configured to
attempt shutdown on the VMs before killing them (daemon-based guest
shutdown, but the same reproduces also with libvirt-guests). The host
is being rebooted.
(virtqemud attempts to shut down guests, but guest takes more than the
configured shutdown inhibition timeout, journald output follows):
06:44:02 fedora systemd-logind[664]: Delay lock is active (UID 0/root, PID 991/virtqemud) but inhibitor timeout is reached.
06:44:02 fedora systemd-logind[664]: System is rebooting.
[...]
06:44:02 fedora virtlogd[802]: 802: debug : virSystemdNotify:667 : Notify 'STOPPING=1'
06:44:02 fedora systemd[1]: Stopping virtlogd.service - libvirt logging daemon...
06:44:02 fedora systemd[1]: Stopping virtqemud.service - libvirt QEMU daemon...
06:44:02 fedora virtqemud[991]: 991: debug : virSystemdNotify:667 : Notify 'STOPPING=1'
06:44:02 fedora systemd[1]: virtlogd.service: Deactivated successfully.
06:44:02 fedora systemd[1]: Stopped virtlogd.service - libvirt logging daemon.
(the shutdown times out, virtqemud kills the unresponsive vm)
06:44:27 fedora virtqemud[991]: 1053: debug : qemuProcessStop:8916 : Shutting down vm=0x7f71ac032670 name=virt-vm1 id=1 pid=805, reason=destroyed, asyncJob=none, flags=0x0
06:44:27 fedora virtqemud[991]: 1053: debug : qemuDomainLogAppendMessage:5757 : Append log message (vm='virt-vm1' message='2026-06-15 10:44:27.427+0000: shutting down, reason=destroyed
) stdioLogD=1
06:44:27 fedora virtqemud[991]: 1053: error : virNetSocketReadWire:1767 : Cannot recv data: Connection reset by peer
06:44:27 fedora virtqemud[991]: 1053: debug : qemuProcessKill:8811 : vm=0x7f71ac032670 name=virt-vm1 pid=805 flags=0x5
Now the log shows that we want to add VM log file message in
'qemuDomainLogAppendMessage' but it fails because virtlogd is dead
already.
Now the same happens also with 'virtlockd' but with much worse outcome,
especially if the configured action is to save the VMs because shutdown
of 'virtlockd' when locks are held ends up 'fencing' the VMs by killing
them.
The same also happens when libvirt-guests is used to shutdown the guests
instead.
This patch adds an explicit 'After=virtlo[ck|g]d.service' to the daemons
containing the qemu driver to ensure that the shutdown ordering makes
sense. This doesn't break socket activation (e.g. the log/lock daemons
are not started unless first invoked).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
While we don't normally try to re-wrap errors to be more descriptive,
probing of qemu capabilities is a special case as the errors can be
cryptic and don't give users enough information about what's going on.
An example is (obtained from a patched qemu which accidentally returned
a broken QMP schema):
$ virsh start VM
error: Failed to start domain 'VM'
error: internal error: Duplicate hash table key 'str'
The error is unusable. On the other hand in 'virQEMUCapsLogProbeFailure'
we do special logging of the caps probing failure with a custom UUID so
that it can be easily found in the logs which reports a much better
error message. Re-raise the same as a normal error too so that the user
gets similar experience:
$ virsh start VM
error: Failed to start domain 'VM'
error: internal error: Failed to probe capabilities for /home/user/git/qemu.git/build/qemu-system-x86_64: internal error: Duplicate hash table key 'str'
This does mean though that the error is logged twice, once via the
custom log entry and second via 'virReportError'. Given that this error
is extremely unlikely, having two log entries IMO doesn't warant
reworking the whole error reporting infra to allow passing extra
metadata just for this one case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When probing of capabilities fails 'qemuProcessQMPStop' kills the qemu
process, but also resets the error. The virResetLastError() was
originally intended to reset the error from 'virProcessKillPainfully',
it also resets any probing error resulting in the following:
$ virsh start VM
error: Failed to start domain 'VM'
error: An error occurred, but the cause is unknown
Keep the error clearing as this might be called on success but preserve
the original error around it.
Fixes: db7b0b12b7
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add async unplug coverage for the setvcpus count-based path.
The test downscales an x86 domain by multiple hotpluggable vCPU entities,
verifying the pending XML before completion, the final XML after DEVICE_DELETED
processing, and one vcpu-removed event for each removed vCPU.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add async unplug coverage for the setvcpu path.
The x86 case covers removal of a single hotpluggable vCPU entity, while the
ppc64 case covers removal of a grouped hotpluggable entity. Both cases verify
the pending XML before DEVICE_DELETED, the final XML after completion, and the
expected vcpu-removed events.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add async CPU hotplug harness support so tests can observe the state
between device_del and DEVICE_DELETED, and then complete the unplug
through the QEMU driver's normal process-event path.
The async path compares the pending live XML, emits DEVICE_DELETED
events via the monitor test helper, waits for the driver worker to
process them, and validates the vcpu-removed events before running the
existing final XML checks.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add qemuMonitorTestEmitDeviceDeleted() so monitor tests can emit a
DEVICE_DELETED event after the command reply has already been consumed.
The helper uses the monitor callback path directly and avoids adding
event JSON to command/reply fixtures.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Async QEMU process events are normally completed through
qemuProcessEventHandler(). Tests that exercise DEVICE_DELETED completion
need to drive that same path instead of mirroring the production logic locally.
Move the declaration to a guarded private header and make the handler
non-static so test code can wire it into a test worker pool. This does not
change runtime behaviour.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
On Linux the accounting stats come from /proc/stat entries and the mapping is:
https://www.kernel.org/doc/html/latest/filesystems/proc.html
VIR_NODE_CPU_STATS_KERNEL = (system + irq + softirq)
VIR_NODE_CPU_STATS_USER = (user + nice)
VIR_NODE_CPU_STATS_IDLE = idle
<VIR_NODE_CPU_STATS_INTR> = N/A, irq is accounted by libvirt as KERNEL
VIR_NODE_CPU_STATS_IOWAIT = iowait
VIR_NODE_CPU_STATS_GUEST = guest
VIR_NODE_CPU_STATS_GUEST was introduced in: b5878727c7
("util: virHostCPUGetStatsLinux: support VIR_NODE_CPU_STATS_GUEST")
with the goal of specifically accounting the CPU time spent running guest VCPUs.
Unfortunately at the time it was not considered that to get a measure of this
time, "guest" is not sufficient, because any guest that is "niced" is accounted
in a separate category, "guest_nice".
This patch rectifies the situation by adding the guest_nice counter, so that
VIR_NODE_CPU_STATS_GUEST = (guest + guest_nice)
which makes the statistic useful to the caller, as the totals sum up correctly.
In order to find the total USER time spent running host tasks, for example:
cpu_user_host = VIR_NODE_CPU_STATS_USER - VIR_NODE_CPU_STATS_GUEST
this follows from the fact that "guest" is included in "user" accounting,
and "guest_nice" is included in "nice" accounting.
Extend the existing tests artificially to capture this specific case.
Fixes: b5878727c7
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The '--type' option of 'attach-interface' command is translated
from string into int using virDomainNetTypeFromString(), IOW the
expected value is from virDomainNetType enum.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The constants for maximum units on a bus are slightly tricky because for
the narrow bus it does not need to account for the extra unit used by
the controller, but the wide and super-wide ones need to.
With this patch a VMX with 64 disks on a pvscsi controller can be
properly parsed.
To properly handle the maximum numbers one of the conditions also needs
to be changed to not allow for units 16 and 65. This does not change
various conditionals in XML parsing and VMX formatting as they need a
significant rewrite. And since that is already working only with the
wide scsi controller (and not the super-wide one) we leave that refactor
for another day as it was done previously.
Tests show this is now possible and they fail before this change.
Resolves: https://redhat.atlassian.net/browse/RHEL-181350
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement domain reboot using the guest agent.
Implementation is very similar to the domain shutdown
added earlier.
Also, change the VIR_DOMAIN_REBOOT_ACPI_POWER_BTN flag
to VIR_DOMAIN_REBOOT_SIGNAL. Even though bhyve emulates
the ACPI button, it's triggered by sending a signal to the
bhyve process, so VIR_DOMAIN_REBOOT_SIGNAL looks like
a more accurate description of communication between
libvirt and bhyve.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement shutdown using a guest agent.
Implementation and behaviour is very similar to the one
found in the qemu driver.
The bhyveDomainShutdownFlags() function now supports
the VIR_DOMAIN_SHUTDOWN_SIGNAL and VIR_DOMAIN_SHUTDOWN_GUEST_AGENT.
If flags were not specified, try the agent first, and if it does
not work, proceed with the signal.
As we do not expect a response from the agent shutdown command,
we do not check qemuAgentShutdown()'s return value. Assume that the
command failed if the agent did not receive EOF, thus "priv->agent"
is not NULL.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The qemuDomainAuthorizedSSHKeysSet() call currently uses
VIR_AGENT_JOB_QUERY. While it's not an issue as this call does not
modify any of the libvirt-stored state, semantically it modifies
the domain, so VIR_AGENT_JOB_MODIFY fits better. Also, similar
calls like qemuDomainSetUserPassword() or qemuDomainSetTime()
already use VIR_AGENT_JOB_MODIFY, so use it in
qemuDomainAuthorizedSSHKeysSet() too.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The detach-interface virsh command requires domain (obviously)
and --type to identify <interface/>. Optionally, --mac can be
provided to chose from multiple interfaces. Well, that renders
--type argument redundant. I mean, if there are but unique MACs
within domain XML, then interface type is implied. If there are
duplicate MACs then --type can help to differentiate, though at
that point detach-device seems like a better fit.
Long story short, make --type optional.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The cleanup section in lxcDomainAttachDeviceNetLive() is
suspicious. It checks @ret for success and adds net into domain
definition. This is not something fits into cleanup. It belongs
right before 'ret = 0' line when we know everything before
succeeded. Moving that piece of code where it belongs, the
cleanup section becomes error because it is executed only in case
of failure.
Change the label to error, fix corresponding goto-s, and drop
@ret variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
During hotplug of an <interface/> into an LXC domain
(lxcDomainAttachDeviceNetLive()), the host side name of the
interface is stored in @veth variable. Well, all possible paths
that set the variable (virLXCProcessSetupInterfaceTap(),
virLXCProcessSetupInterfaceDirect()) document it is caller's
responsibility to free the memory. But it never does so.
==49848== 12 bytes in 2 blocks are definitely lost in loss record 68 of 1,763
==49848== at 0x4913888: malloc (vg_replace_malloc.c:447)
==49848== by 0x546F0BC: __vasprintf_internal (in /usr/lib64/libc.so.6)
==49848== by 0x5077A70: g_vasprintf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x50404DB: g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x50405A4: g_strdup_printf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x4A8591E: virNetDevGenerateName (virnetdev.c:3573)
==49848== by 0x4A93C38: virNetDevVethCreate (virnetdevveth.c:124)
==49848== by 0xED6C505: virLXCProcessSetupInterfaceTap (lxc_process.c:279)
==49848== by 0xED5F7A7: lxcDomainAttachDeviceNetLive (lxc_driver.c:3517)
==49848== by 0xED60D24: lxcDomainAttachDeviceLive (lxc_driver.c:3925)
==49848== by 0xED6262D: lxcDomainAttachDeviceFlags (lxc_driver.c:4453)
==49848== by 0xED62819: lxcDomainAttachDevice (lxc_driver.c:4485)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When staring an LXC domain (well, container) its consoles are
opened and each one is assigned an alias (for later use with
virDomainOpenConsole()). Now, before generating new alias the old
one is freed. But the old one can never be anything other than
NULL. The domain is inactive at this point (we are in process of
starting it, after all). And LXC driver does not support user
aliases, yet.
Just drop the pointless g_free().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
'qemuValidateDomainDeviceDefVideo' ensures that only the correct video
device models are selected as well as that only QXL and VIRTIO video
devices can be selected as secondary.
Remove unnecessary checks and simplify the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virtio video device frontend type is either selected by the
post-parse code based on capabilities or provided by the user/existing
XML explicitly. No need to try to come up with a model when generating
commandline based on broken logic.
The difference in test output shows:
- honours user's config in case of the new 'device' attribute
- shows how incorrect fallback would be used for 'virtio-vga-gl'
(picked virtio-vga (non-gl) instead of 'virtio-gpu-gl')
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The currently existing checks are broken:
- only QEMU_CAPS_DEVICE_VHOST_USER_GPU is checked for vhostuser
backends (vhost-user-vga is actually separately packaged)
- the check for the 3d accelerated (-gl) versions checks only if one
of them exists (the commandline formatter picks a non-gl afterwards)
- 'virtio-vga'/'virtio-gpu' is not checked at all
The code also doesn't yet check if, when the user passes the new
'device' property manually the config actually makes sense.
To fix all of the above introduce a table of supported frontend devices
as well as properties that need to be checked for them.
This requires fixing a recently-introduced test case which shows a
nonsensical situation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Historically 'virtio-vga' was always picked as the first '<video>'
(virtio) device and any sub-sequent ones were 'virtio-gpu'. When support
for aarch64 VMs was being added an exception to use 'virtio-gpu' for the
primary device was added as aarch64 doesn't have anything resembling the
"legacy" 'VGA' interface. At this point this exception was only for
aarch64. The distinction between 'virtio-vga' and 'virtio-gpu' was *not*
recorded in the VM XML as it was a new feature (for aarch64) and it
didn't make sense to pick 'virtio-vga'.
Some time later the following commit:
commit 4c029e8cfa
Author: Pavel Hrdina <phrdina@redhat.com>
Date: Fri Sep 30 14:41:37 2016 +0200
qemu_command: properly detect which model to use for video device
This improves commit 706b5b6277 in a way that we check qemu capabilities
instead of what architecture we are running on to detect whether we can
use *virtio-vga* model or not. This is not a case only for arm/aarch64.
modified the code to do this picking by checking presence of
'virtio-vga' device instead. That approach didn't consider the fact that
the modular deployment of qemu allows for the 'virtio-vga' device to be
missing in certain cases, thus introducing a latent bug as we'll pick
'virtio-gpu' in such case but don't record it anywhere.
Now this creates a problem, if the deployments differ, because you can
have two *incompatible* (at migration stream level) setups which are
based on the same identical XML without the possibility for the
destination libvirt instance during migration to pick which is the
correct one.
To prevent this and actually fix any existing such deployment (which
allows upgrade of libvirt daemons on the source) we will record the
picked device frontend at post-parse time into the XML. This luckily
properly handles running VMs even if 'virtio-vga' were already
installed since we record the actual qemuCaps we've started the VM with.
Now 'virtio-vga' vs 'virtio-gpu' is not the only broken piece of logic.
In fact 'virtio-vga-gl' could have been downgraded to 'virtio-vga' based
on some very weird logic (see comments in code for explanation).
The logic in 'qemuDomainDeviceVideoDefPostParse' re-creates the logic
used to setup virtio-vga vs. virtio-gpu, and 'vhost-user-vga' vs.
'vhost-user-gpu' as those still make sense. For the 'gl' variants two
versions exist, one meant to recover running VMs and one for new VMs
where the broken logic makes no sense.
Now this patch just records what was selected into the XML, but doesn't
yet modify the commandline to actually use that value verbatim (e.g. if
the user specified an actual non-default value already).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There's no point in falling through to the check reporting invalid
type since if the code picks a model that one will be valid.
Reorganize the code so that we can return final decision right away.
This means that the two flags 'virtio' and 'virtioBusSuffix' need to be
set prior to the return.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a test case demonstrating the switch to 'virtio-gpu' on a host which
would normally pick 'virtio-vga'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU's commandline generator picks for virtio video between various
actual device models not only based on the XML definition but also
capabilities present. Since none of the devices is actually ABI
compatible we need to record the actually selected device in the XML.
Introduce 'device' attribute:
<video>
<model type='virtio' heads='1' primary='yes' device='virtio-gpu'/>
which will record the actually selected model so that we can preserve
ABI across restarts on deployment changes but more importantly across
migrations where the deployment differs.
The code specifically avoids an ABI stability check for the new field
because there are already possibly broken configurations that the users
may want to fix by picking the proper model which could be forbidden.
Users are instructed to not set the field in the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add example of two running configs with distinct recorded capabilities
(presence of QEMU_CAPS_DEVICE_VIRTIO_VGA at startup) which will
demonstrate the recording of the picked actual device type on the
commandline.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Similarly to previous patch add testing of 'virtio-gpu-gl' or
'virtio-vga-gl' with missing the respective capabilities, but this time
allowing VIR_DOMAIN_DEF_PARSE_ABI_UPDATE.
This will later on show that in case when the fallback can't be honoured
the code will not pick a device that doesn't support acceleration (the
non-gl variant).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The capability check in 'qemuValidateDomainDeviceDefVideo' which
validates whether a <video> definition with acceleration enabled is
possible is only aggregate, thus validates that any '-gl' video backend
is available.
Since qemu compiles each backend into a separate module it's possible to
have an installation where 'virtio-gpu-pci-gl' exist but 'virtio-vga-gl'
doesn't and it will not be rejected at validation. The commandline
though will generate a device *without* the '-gl' which is ABI
incompatible with the counterpart which does have '-gl', but the VM
starts. If such a VM is then migrated to a deployment which does have
the '-gl' variant available, migration will fail because qemu will
generate the '-gl' device as we don't record this fact in the XML.
This test case captures this situation which will be fixed later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The test case shows that if the 'QEMU_CAPS_DEVICE_VIRTIO_VGA' capability
is not present (e.g. if the corresponding qemu module isn't installed)
libvirt will pick:
-device '{"driver":"virtio-gpu-pci", ...
instead of:
-device '{"driver":"virtio-vga", ...
but without any discernable difference in the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will add additional testing for various virtio-*-gl
devices, including filling of the default model. The output file needs
to not influnece the input for this test to work properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When querying capabilities for the default emulator with no other
arguments (e.g. 'virsh domcapabilities) fix error whithout emulator
installed an error is reported but the error would mention '(null)'
architecture:
# virsh domcapabilities
error: failed to get emulator capabilities
error: unsupported configuration: unable to find any emulator to serve '(null)' architecture
This happens as the error formatting takes 'archStr' which is NULL for
the default architecture instead of using 'arch' which is populated by
the host's architecture and converting it back.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The user configuration of added/removed qemu capabilities via the qemu
namespace element was applied only right before generating a
commandline, but the post parse code code didn't see these.
Apply the capability modification prior to running post parse code so
that defaults are properly picked based on the configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The user configuration of added/removed qemu capabilities via the qemu
namespace element was applied only right before generating a
commandline, but the validation code didn't see these.
Modify the validation entry points so that they apply this optionally.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move and rename the function to 'qemuDomainUpdateCustomCapabilities' and
modify the arguments so that it will be possible to reuse it also in the
post-parse and validation code which ought to base decisions on the same
logic as VM startup would.
Since copying of the qemu capabilities object is very expensive (I've
observed an almost 4x slowdown of qemuxmlconftest)
'qemuDomainUpdateCustomCapabilities' copies the capabilities only when
necessary.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patch will add a function which will need to optionally copy
passed capabilities for modification. Export 'virQEMUCapsNewCopy'
outside of tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'capability_filters' allows admins to globally disable some qemu
capabilities via the config file.
Until now it was applied only directly when starting the VM, but that is
too late as the capability is still present when e.g. the post-parse
code is picking defaults.
Rework the code so that 'capability_filters' is applied directly after
probing qemu so all existing capabilities will lack the filtered out
ones.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This new parameter was added as part of commit ee06a78790 ("remote: allow
passing argv to the ext transport").
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Switch from openSUSE Leap 15.5 to 16.0. Not just CI build job,
but also codestyle_job which runs on Leap too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bhyveConnectAgent() function calls qemuAgentOpen() to open an agent
connection. If it fails, e.g. because of insufficient permissions to
open the socket, it returns NULL. Currently, if that happens,
bhyveConnectAgent() just sets agentError to true and exits with 0.
This does not match the contract of bhyveDomainEnsureAgent(), which
should either provide an agent connection or fail.
Fix that by returning -1 when qemuAgentOpen() fails. To make intent
clearer, add a documentation for bhyveConnectAgent().
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark
Марко Костић (Marko Kostić)
Fco. Javier F. Serrador
Ján Tomko
Denis V. Lunev
Michal Privoznik
Peter Krempa
Akash Kulhalli
Claudio Fontana
Martin Kletzander
Roman Bogorodskiy
Mark Cave-Ayland