Move the setup of the 'vdpa' netdev into the new helper shared between
commandline and hotplug code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The helper will aggregate code that is used to connect the network
backend to the corresponding host portion.
This will be used to refactor the duplicated code between the cold-start
and hotplug helper functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prepare for the upcoming refactor to use qemuFDPass for all the network
related file descriptors:
- tapfds
- vhostfds
- slirp
- vdpa
This patch adds the private data variables and a utility function to
clear it. Clearing is useful since we don't really need the data once
the VM is running so we save some memory.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While the FDs are closed right after use to prevent leaks, at certain
point we don't need the whole helper any more. Clear them for char
devices after hotplug and on start.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We don't want to keep the FDs open more than we need to.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only caller doesn't use the fdset info any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If we use our own fdset ID when hot-adding a fdset we can vastly
simplify our internals.
As a stop-gap when a fdset would be added behind libvirt's back we'll
validated that the fdset to be added is not yet used.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While 'add-fd' qmp command gives the possibility to find an unused fdset
ID when hot-adding fdsets, such usage is extremely inconvenient.
This patch allows us to track the used fdset id so that we can avoid the
need to check results and thus employ simpler code flow when hot-adding
devices which use FD passing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code didn't check that the reply value is an array and that the
'fds' array is present. This could lead to a crash if qemu wouldn't
return an array in those places.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt doesn't use the returned value and in fact there's nothing we
could even do with them. Avoid parsing and storing them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We use the qemuFDPass infrastructure when building the command line,
refactor the monitor too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's effectively replaced by checks in qemuFDPassTransfer. This will
simplify cleanup paths on constructing the qemuFDPass object when FDs
are being handled.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add validation to the transfer step to make the adding step more simple
for easier cleanup paths.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add possibility to delay checks to the point when the FDs are to be
passed to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Calling virDomainRestoreFlags() with no typed params results in
an error in open() because it tries to open a NULL path.
Obviously, this is wrong and path to restore from must be
provided, at least for now until other sources of restore are
introduced. Then this limitation can be relaxed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When no VIR_DOMAIN_SAVE_PARAM_FILE typed param is set when
calling virDomainSaveParams() then in turn virQEMUFileOpenAs()
tries to open a NULL path.
We have two options now:
1) require the typed param, which in turn may be promoted to a
regular argument, or
2) use this opportunity to make the API behave like
virDomainManagedSave() and use typed params to pass extra
arguments, instead of having to invent new managed save API
with typed params.
Let's go with option 2, as it is more future proof.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The code that actually does managed save within
qemuDomainManagedSave() is going to be reused shortly. Move it
out into a separate helper.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The qemuDomainManagedSavePath() function does no more than a
g_strdup_printf() and as such can't return NULL really.
Therefore, don't check for its return value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Every running QEMU process we are willing to reconnect (i.e., at least
3.1.0) supports migration events and we can assume the capability is
already enabled since last time libvirt daemon connected to its monitor.
Well, it's not guaranteed though. If libvirt 1.2.17 or older was used to
start QEMU 3.1.0 or newer, migration events would not be enabled. And if
the user decides to upgrade libvirt from 1.2.17 to 8.4.0 while the QEMU
process is still running, they would not be able to migrate the domain
because of disabled migration events. I think we do not really need to
worry about this scenario as libvirt 1.2.17 is 7 years old while QEMU
3.1.0 was released only 3.5 years ago. Thus a chance someone would be
running such configuration should be fairly small and a combination with
upgrading 1.2.17 to 8.4.0 (or newer) with running domains should get it
pretty much to zero. The issue would disappear ff the ancient libvirt is
first upgraded to something older than 8.4.0 and then to the current
libvirt.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
All QEMU versions we care about support migration events and we should
be able to enable the associated capability when connecting to the
monitor. Failure to do so is thus considered fatal now.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The code was a bit too complicated, especially after removing the check
for QEMU_CAPS_MIGRATION_EVENT.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
All QEMU versions we care about already support migration events.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
A few commits ago new APIs were introduced (virDomainSaveParams()
and virDomainRestoreParams()) and with them new typed parameters:
VIR_SAVE_PARAM_FILE and VIR_SAVE_PARAM_DXML. But their name does
not suggest they apply to either of the APIs nor that they are
intended for domain related APIs. Switch to
VIR_DOMAIN_SAVE_PARAM prefix to make it obvious.
It's true we already have VIR_DOMAIN_SAVE_* symbols which are
part of virDomainSaveRestoreFlags enum, therefore stick also with
'_PARAM_ ' part of the name to differentiate the two.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For most of them qemu errors out with unclear message, and for the
audiodev qemu just falls back to timer-based audio with a warning
message, and will possibly also error out in the future.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2035163
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After previous cleanup the 'error' label in
qemuDomainObjPrivateXMLParse() contains nothing but a return
statement. Well, the label can be dropped and all 'goto'-s can be
replaced with the return statement directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuDomainObjPrivateXMLParse() is responsible for parsing
given XML into qemuDomainObjPrivate struct. As it does so, memory
might be allocated for some members. If an error occurs during
parsing the control jumps onto 'error' label where only some of
previously allocated memory is freed. The reason there's no
memory leak is simple: the only caller (virDomainObjParseXML())
unrefs freshly created virDomainObj which in turn causes
qemuDomainObjPrivateFree() to be called. Therefore, these
partial, selective frees are needless and should be just dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that qemuDomainObjPrivate struct gained new member format it
into XML and parse it so that the value is preserved across
daemon restarts.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since v1.3.0-90-gafbe1d4c56 the original value of memlock limit
is stored inside virDomainObj struct directly (under
originalMemlock member). This is needless because the value is
used only inside QEMU driver and thus can reside in
qemuDomainObjPrivate struct.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add the ability to configure a qemu-vdagent in guest domains. This
device is similar to the spice vdagent channel except that qemu handles
the spice-vdagent protocol messages itself rather than routing them over
a spice protocol channel.
The qemu-vdagent device has two notable configuration options which
determine whether qemu will handle particular vdagent features:
'clipboard' and 'mouse'.
The 'clipboard' option allows qemu to synchronize its internal clipboard
manager with the guest clipboard, which enables client<->guest clipboard
synchronization for non-spice guests such as vnc.
The 'mouse' option allows absolute mouse positioning to be sent over the
vdagent channel rather than using a usb or virtio tablet device.
Sample configuration:
<channel type='qemu-vdagent'>
<target type='virtio' name='com.redhat.spice.0'/>
<source>
<clipboard copypaste='yes'/>
<mouse mode='client'/>
</source>
</channel>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This enumeration will be useful for vnc with the upcoming qemu-vdagent
device so make the name more generic.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Detect whether qemu supports the qemu-vdagent character device. This
enables support for copy/paste with VNC graphics.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There's no real difference between
qemuSecurityStartVhostUserGPU() and qemuSecurityCommandRun(). The
latter is used more frequently while the former has just one
user. Therefore, drop the less frequently used one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It allows libvirt to provide the value of cpu0-id retuned by the Qemu QMP
command query-sev-capabilities as implemented by the Qemu Patch [1] which
is merged to Qemu master branch and should be available with Qemu 7.1.
This is used to get the signed Chip Endorsement Key (CEK) of the CPU of AMD
system from AMD's Key Distribution Service (KDS).
Similar to cbitpos, reducedPhysBits, maxGuests & maxESGuests;
the value of cpu0-id is also provided using 'virsh domcapability'.
[1] https://lore.kernel.org/all/20220228093014.882288-1-dovmurik@linux.ibm.com/
Signed-off-by: Niteesh Dubey <niteesh@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We do not need VIR_DOMAIN_VIRT_QEMU to get qemu default
version. With the 'os_type' and 'arch'in capabilities,
we could identify 'emulator' which is enough to get the version.
Actually VIR_DOMAIN_VIRT_QEMU is not the only domain virt type for
qemu driver, there are VIR_DOMAIN_VIRT_KVM and VIR_DOMAIN_VIRT_HVF.
If TCG is disabled in qemu, it will cause the error that could not
find suitable emulater when access version.
Signed-off-by: Liang Yan <lyan@digtalocean.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The iSCSI hostdev code doesn't require the check for the empty drive
and the check for the protocol because those are already guaranteed at
that point.
In qemuDomainSecretStorageSourcePrepare we don't need to check the
network disk type either as it's now guaranteed by the definition
validator.
Thus both callers can simply check whether src->auth is present and the
helper can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since we are already checking that the encryption format can be only
_LUKS and _LUKS2 this wrapper function doesn't make much sense any more.
The only one caller can do this internally.
The move of virStorageSourceIsEmpty is correct as there are no secrets
to setup if the disk is empty anyways.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The validation should be the only point to decide whether authentication
is supported for a disk backing protocol. The rest of the code can then
simply always enable it.
This also fixes a crash when authentication is requested e.g. for a HTTP
backed disk as the blockdev props formatter expects that it was already
set up.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the impossible error message about the 'qcow2' encryption format
not being supported. We validated before that it can't happen.
Additionally the code can be simplified by removing error handling from
impossible code paths as the last resort is virJSONValueCreate not
allowing NULL argument with the 's:' modifier.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reject encryption requests for unsupported image format types.
Add negative test for the rejected cases as well as modify
'disk-network-rbd-encryption' case to validate that with librbd
encryption the format doesn't matter.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the two ad-hoc checks below into the block which already tests
whether encryption is requested.
If we first disallow the old-style qcow2 encryption we can remove a
whole block of validation later on.
Also the capability check for qcow2+luks can be simplified by moving it
into the same block.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is a quite an old (created at 2016) patch fixing an issue for at
that time contemporary Fedora 23. virsh reboot returns success (yet
after hanging for a while), VM is rebooted sucessfully too but then
shutdown from inside guest causes reboot and not shutdown.
VM has agent installed. So virsh reboot first tries to reboot VM thru
the agent. The agent calls 'shutdown -r' command. Typically it returns
instantly but on this distro for some reason it takes time. I did not
investigate the cause but the command waits in dbus client code,
probably waits for reply. The libvirt waits 60s for agent command to
execute and then errors out. Next reboot API falls back to ACPI shutdown
which returns successfully thus the reboot command return success too.
Yet shutdown command in guest eventually successfull and guest is truly
rebooted. So libvirt does not receive SHUTDOWN event and fake reboot
flag which is armed on fallback path stays armed. Thus next shutdown
from guest leads to reboot.
The issue has 100% repro on Fedora 23. On modern distros I can't
reproduce it at all. Shutdown command is asynchronous and returns
immediately even if I start some service that ignores TERM signal and
thus shutdown procedure waits for 90s (if I not mistaken) before sending
KILL.
Yet I guess it is nice to have this patch to be more robust.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Nikolay Shirokovskiy <nikolay.shirokovskiy@openvz.org>
When <qemu:override> is the only usage of the qemu namespace the entire
section is mistakenly removed. Add check for use count.
Signed-off-by: Justin Gatzen <justin.gatzen@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The point of qemu_processpriv.h file is to allow a small subset
of functions to be called from test suite but not elsewhere. This
is implemented by requiring everybody that includes the file to
define a macro. If not done so, an error is printed at compile
time. However, this error message contains a typo because it
mentions qemu_process_priv.h while the file is called
qemu_processpriv.h.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
