There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virNetMessageQueuePush() appends by walking to the tail of the queue. If
it is handed a message which is already in that queue, and that message
happens to be the tail, it links the message to itself. The cycle then
makes virNetMessageQueueServe() return the same pointer on consecutive
calls, and callers which free what they are served - such as
virNetServerClientDispatchWrite() - free it twice, aborting the process
with "free(): invalid pointer".
Refuse such a push and warn instead, so that a caller bug shows up as a
diagnosable log message rather than as heap corruption some time later.
The check has to walk the queue rather than just test msg->next, because
virNetMessageClear() memsets the whole message: a queued message which
has been cleared appears unlinked while still being referenced.
Also break the cycle in virNetMessageQueueServe() if one is somehow
already present, rather than handing out the same message indefinitely,
and clear msg->next in virNetMessageFree() so a stale reference held by a
queue is detectable instead of dangling.
The accompanying test reproduces the self-cycle deterministically: with
the check removed it fails with "Message linked to itself".
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Ross Golder <ross@golder.org>
When a stream write fails, daemonStreamHandleWriteData() reports the
error to the client via virNetServerProgramSendReplyError(), which takes
ownership of 'msg' and queues it on client->tx. It then returns that
function's return value, which is 0 on success.
Its caller daemonStreamHandleWrite() treats 0 as "the handler did not
send anything", so for VIR_NET_CONTINUE it clears the message and queues
it a second time to release the client's request slot. As the message is
by then the sole element of client->tx, virNetMessageQueuePush() walks to
the tail - which is the message itself - and links it to itself. The
resulting cycle makes virNetMessageQueueServe() hand out the same pointer
twice, and virNetServerClientDispatchWrite() frees it twice:
libvirtd[109078]: free(): invalid pointer
systemd[1]: libvirtd.service: Main process exited, code=dumped,
status=6/ABRT
The daemon then crash-loops until systemd's start limit is reached.
Note that virNetMessageClear() memsets the whole message, including
->next, so the doubly-queued message looks unlinked and the condition is
not detectable by inspecting msg->next alone.
Give the handlers a distinct return value 2, meaning "fully processed and
already queued, the caller must not touch msg again", and honour it in
daemonStreamHandleWrite(). The requeue test changes from "ret > 0" to
"ret == 1" - otherwise the new value would requeue a message which is
already on client->tx.
daemonStreamHandleHole() had the identical defect and is fixed the same
way. daemonStreamHandleFinish() and daemonStreamHandleAbort() also
consume the message, but are only reached for VIR_NET_OK and
VIR_NET_ERROR respectively, so the VIR_NET_CONTINUE re-send never applies
to them.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/902
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Ross Golder <ross@golder.org>
CVE-2026-77158
In case of hitting the cleanup label, the disks array
was freed but the pointer was not cleared, leading
to a possible double free.
Fixes: 0cb2d9f05d (v6.10.0-9-g0cb2d9f05d)
Closes: https://gitlab.com/libvirt/libvirt/-/work_items/910
Reported-by: David Korczynski (Ada Logics)
Found-by: Claude
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve allows to set eui64 for the NVMe disks:
eui64 IEEE Extended Unique Identifier (8 byte value).
And in a real command line:
-s 5:0,nvme,/data/img/10gb.img,ser=BHYVE-NVME01-F000,eui64=0x01000000efbeadde
Model that using the <wwn> element:
<disk type='file'>
<driver name='file' type='raw'/>
<source file='/path/to/some.img'/>
<target dev='nvme0n1' bus='nvme'/>
<wwn>01000000efbeadde</wwn>
</disk>
As this element does not allow commas, it's not necessary to add
additional validation for that.
Closes: https://gitlab.com/libvirt/libvirt/-/work_items/901
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
bhyve supports setting NVMe controller serial number using
the "ser=<SN>" option. Update bhyveBuildNVMeControllerArgStr()
to set that if "serial" is specified for the controller.
We do it in the controller's disks loop, but as we prohibit more than 1
disk per controller in bhyveDomainDefValidate(), there is no
repetition here.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
bhyve supports passing disk serial number using the "ser=<SN>"
option, so update bhyveBuildAHCIControllerArgStr() to set it
from the "serial" element.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
As bhyve options are passed as a comma separated list, e.g.:
-s N:0,ahci,hd:/tmp/my.img,nmrr=7200,ser=BHYVE-SER01-0001
Do not allow using "," in the serial name. This applies to both NVMe and
SATA disks.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Attaching a vfio-ccw mediated device as a <hostdev> fails under the
libvirt-qemu AppArmor profile because QEMU's channel subsystem code
(hw/s390x/css.c) reads several sysfs attributes of the passed-through
subchannel when building the guest SCHIB, and the profile does not grant
read access to them:
css_sch_get_chpids() -> /sys/bus/css/devices/<id>/chpids
css_sch_get_path_masks() -> /sys/bus/css/devices/<id>/pimpampom
css_sch_get_chpid_type() -> /sys/devices/css<n>/chp0.<chpid>/type
The first two are opened via /sys/bus/css/devices/<id> symlinks, which
AppArmor resolves to the real device path /sys/devices/css<n>/<id>/
before mediating the access; the CHPID type file is read directly under
/sys/devices/. Without these rules the attach (or hotplug) fails with an
AppArmor DENIED message and QEMU aborts with:
s390_ccw_realize: Failed to build initial schib: Invalid argument
Add narrowly-scoped read rules for these three files so vfio-ccw
passthrough works without granting broad access to /sys/devices/css*.
Signed-off-by: Hector Cao <hector.cao@canonical.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Extend iothreadset to allow configuring the iothread poll-weight value
from the command line.
Add a --poll-weight option to opts_iothreadset and wire it up in
cmdIOThreadSet. If the option is omitted the parameter
is not added to the list and the backend leaves the value unchanged.
Document --poll-weight in the iothreadset section of the virsh manpage
and update the syntax synopsis to include the new option. Extend the
virsh test suite with an iothreadset --poll-weight 3 call followed by
a domstats check that confirms the updated value is reflected.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add poll-weight support to the test driver so that the virsh test
suite can exercise the iothreadset --poll-weight path end-to-end.
Add a poll_weight field to the testIOThreadInfo struct and initialise
it to 0 in both testDomainGenerateIOThreadInfos and
testDomainAddIOThread. Extend testDomainIOThreadParseParams to accept
and store VIR_DOMAIN_IOTHREAD_POLL_WEIGHT, and extend
testDomainGetStatsIOThread to emit the value via domstats.
Update the expected iothreads.out output to include the poll-weight=0
field in the existing domstats blocks now that the test driver reports
it unconditionally.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Wire the poll-weight setting into the QEMU command line, monitor, and
driver-side parameter handling.
Add poll-weight to the iothread object properties when building the
QEMU command line. Add the live setter in the monitor JSON layer using
a new VIR_IOTHREAD_SET_PROP_UINT macro consistent with the existing UL
variant. Wire up typed parameter parsing with an explicit range check
for [0, 63] and propagate the value into the persistent domain
definition on hotplug. Guard the live path with a capability check.
Add a CAPS check in the domain validator and remove the now-unnecessary
break from the thread pool validation loop since the loop must continue
to check poll-weight on every iothread.
Also add VIR_DOMAIN_IOTHREAD_POLL_WEIGHT typed parameter constant and
a qemuxmlconf test case for the new functionality.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add support for reading the iothread poll-weight value from QEMU and
exposing it via domain stats.
Add poll_weight and set_poll_weight fields to qemuMonitorIOThreadInfo
and parse the poll-weight property from the QMP query-iothreads
response. The property is optional and only present on newer QEMU
binaries.
Expose the fetched value through the domain stats interface by adding
VIR_DOMAIN_STATS_IOTHREAD_SUFFIX_POLL_WEIGHT and reporting it in
qemuDomainGetStatsIOThread when the value is available.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add a capability flag for the iothread poll-weight property.
Detect support for the property from the QMP schema so that libvirt
can conditionally expose and use poll-weight only with QEMU binaries
that support it.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Document the iothread poll-weight XML attribute in formatdomain.
Extend the description of iothread polling controls to cover the new
poll-weight attribute and how it relates to the existing poll-max,
poll-grow, and poll-shrink settings. Also document the accepted
range and the meaning of zero as a request for the hypervisor
default.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add support for the iothread poll-weight XML attribute.
Store the value in the internal iothread definition, parse it from
the <poll/> element, and format it back into domain XML. Also extend
the schema to accept the new attribute and enforce the accepted
range of [0, 63] in the domain validator.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For NVRAM storage specifically, the guest-visible size is critical to
correct handling of the OVMF address space. Allow specifying storage
slices for NVRAM storage when the underlying block may be larger
due to alignment/allocation restrictions.
As qemuPrepareNVRAMBlock() does not support it, disallow slices with
non-raw formats, and slice offsets.
Signed-off-by: John Levon <john.levon@nutanix.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
'virStorageFileGetEncryptionPayloadOffset' expects payloadOffset + 4 to
be in buffer bounds which isn't checked anywhere.
For example malicious actor may provide LUKS header with just magic and
version like: '4c554b53 babe 0001'. This example successefully passes
'virStorageFileHasEncryptionFormat' and leads to OOB read of 4 bytes.
So the fix is to add bounds checks.
Fixes: b7d44f450c
Closes: https://gitlab.com/libvirt/libvirt/-/work_items/906
Signed-off-by: Sergey Zhidkih <rx1513@altlinux.org>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
libvirt chown()s the swtpm log file to the swtpm user:group when starting
a VM. The swtpm log directory is writable by swtmp user, who could replace
the logfile with a symlink to a root-owned path. At next VM start, libvirt
will chown() that path to the swtpm user:group, which breaks the intended
separation between the confined swtpm account and root-owned files.
Use fchown() on an fd opened with O_NOFOLLOW to avoid the potential
symlink attack.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Provide sample XML and CLI args for the cmdqv XML schema.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Introduce support for "cmdqv" IOMMU attribute, which enables NVIDIA
Tegra241 CMDQV, an extension for ARM SMMUv3. It supports passthroughs
of physical SMMU-CMDQ linked command queue from host space to a VM.
Reject domain configs that set cmdqv when the QEMU binary lacks the
property.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Probe the arm-smmuv3 cmdqv device property via device-list-properties,
gated on QEMU_CAPS_DEVICE_ARM_SMMUV3.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When parsing disk source in ESX driver (esxParseVMXFileName())
the datastore is traversed through trying to find matching
prefix. But not every datastore has to be mounted. In that case,
esxVI_LookupDatastoreHostMount() returns success and the returned
struct has mountInfo->path set to NULL. This can be deducted from
the following backtrace (which shows that strlen() hidden in
STRSKIP() macro was given NULL pointer).
Thread 1 "virsh" received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
76 VPCMPEQ (%rdi), %ymm0, %ymm1
(gdb) bt full
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
No locals.
#1 0x00007ffff7c292d7 in esxParseVMXFileName (fileName=0x5555557341d0 "/vmfs/volumes/5f64209f-c0af0aa8-70c4-e4434ba73190/msafra-RHEL9-shared-1/msafra-RHEL9-shared-1_1.vmdk", opaque=0x7fffffffcf80,
out=0x7fffffffc738, allow_missing=false) at ../src/esx/esx_driver.c:172
data = 0x7fffffffcf80
propertyNameList = 0x555555738b50
datastoreList = 0x55555573cf40
datastore = <optimized out>
hostMount = 0x555555733640
datastoreName = 0x55555573e590 "mnecas-nfs-test"
tmp = <optimized out>
saveptr = 0x5555556a5b50 ""
strippedFileName = 0x0
copyOfFileName = 0x0
directoryAndFileName = <optimized out>
ret = -1
__FUNCTION__ = "esxParseVMXFileName"
#2 0x00007ffff7bd47f4 in virVMXParseDisk (ctx=ctx@entry=0x7fffffffcfb0, xmlopt=xmlopt@entry=0x555555738d80, conf=conf@entry=0x5555556a5b50, device=device@entry=0, busType=<optimized out>, busType@entry=3,
controllerOrBus=controllerOrBus@entry=1, unit=<optimized out>, def=0x7fffffffc960, vmdef=0x5555557375a0) at ../src/vmx/vmx.c:2553
tmp = 0x0
result = -1
prefix = 0x5555557384d0 "scsi1:0"
present_name = "scsi1:0.present", '\000' <repeats 16 times>
present = true
startConnected_name = "scsi1:0.startConnected\000\000\000\000\000\000\000\000\000"
startConnected = true
deviceType_name = "scsi1:0.deviceType", '\000' <repeats 13 times>
deviceType = 0x555555737f60 "scsi-hardDisk"
clientDevice_name = "scsi1:0.clientDevice", '\000' <repeats 11 times>
clientDevice = false
fileType_name = "scsi1:0.fileType", '\000' <repeats 15 times>
fileType = 0x0
fileName_name = "scsi1:0.fileName", '\000' <repeats 15 times>
fileName = 0x5555557341d0 "/vmfs/volumes/5f64209f-c0af0aa8-70c4-e4434ba73190/msafra-RHEL9-shared-1/msafra-RHEL9-shared-1_1.vmdk"
writeThrough_name = "scsi1:0.writeThrough", '\000' <repeats 11 times>
writeThrough = false
mode_name = "scsi1:0.mode", '\000' <repeats 19 times>
mode = 0x0
cleanup = <optimized out>
__FUNCTION__ = "virVMXParseDisk"
#3 0x00007ffff7bd5f01 in virVMXParseConfig (ctx=0x7fffffffcfb0, xmlopt=0x555555738d80, caps=<optimized out>, vmx=<optimized out>) at ../src/vmx/vmx.c:1749
#4 0x00007ffff7c35319 in esxDomainGetXMLDesc (domain=<optimized out>, flags=0) at ../src/esx/esx_driver.c:2595
#5 0x00007ffff7cc4fd3 in virDomainGetXMLDesc (domain=domain@entry=0x5555557367f0, flags=flags@entry=0) at ../src/libvirt-domain.c:2898
#6 0x0000555555586cca in cmdDumpXML (ctl=0x7fffffffd1d0, cmd=0x5555556a5450) at ../tools/virsh-domain.c:10787
#7 0x00005555555bc7cb in vshCommandRun (ctl=0x7fffffffd1d0, cmd=0x5555556a5450) at ../tools/vsh.c:1383
#8 0x0000555555562fbc in main (argc=<optimized out>, argv=0x7fffffffd5c8) at ../tools/virsh.c:900
The backtrace was trimmed.
To fix this, just check whether mount path is not NULL before
passing it to STRSKIP().
Resolves: https://redhat.atlassian.net/browse/RHEL-213506
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In commit aa1bf13b9c I attempted to fix
the ordering of virtlockd and virtlogd during shutdown but I made a typo
in the name of 'virtlockd.service' (missing 'd').
Fixes: aa1bf13b9c
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The virDomainGetGuestInfo() API is exposed as 'guestinfo'
command. Introduce new --devices option for it to reflect
introduction of VIR_DOMAIN_GUEST_INFO_DEVICES type.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Use freshly introduced qemuAgentGetGuestDeviceInfo() to implement
support of VIR_DOMAIN_GUEST_INFO_DEVICES type of
virDomainGetGuestInfo() API in the bhyve driver.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Introduce a test case for newly introduced
qemuAgentGetGuestDeviceInfo(). The expected data started as a
genuine reply from a qemu-ga running inside a Windows VM. But
then was modified to cover more cases (like an optional key
missing).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
QEMU agent has 'guest-get-devices` command. Even though it's
currently implemented only for Windows, it shows some interesting
information from inside the guest, like device drivers, their
versions, and so on.
Looking at the command definition in qga/qapi-schema.json the
only non-optional field in returned data is 'driver-name'. The
rest is optional. Although looking at the current implementation
either all fields are set or device is ignored completely.
Nevertheless, our code should follow QMP schema.
New qemuAgentGuestDeviceInfo structure is introduced among with
qemuAgentGetGuestDeviceInfo() function which parses reply from
agent and fills the structure. Optional fields are either set to
NULL or -1, if missing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
QEMU guest agent has 'guest-get-devices` command, which returns
information on guest devices (driver name, version, release date,
and so on). In this commit the public API part is introduced.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The image metadata crawler code generally forbids qcow2 images which
have a 'backing_file' but don't specify a 'backing_file_fmt' header as
we don't want to probe the format due to security implications.
There's one notable exception for the last image in the chain which can
be format probed if it doesn't have another 'backing_file'.
As the comment in 'virStorageSourceGetMetadataRecurse' suggests we don't
want to allow the probe if anything probed would influence access to
more resources. Unfortunately that didn't involve 'data_file' header
which gives more access.
Fortunately there is no way for a guest OS having a 'raw' disk and
access to libvirt's snapshot API to abuse this as libvirt's snapshot API
does specify the header. Other cases where an arbitrary image is passed
to libvirt can 'backing_file'+'backing_file_fmt' directly to access
arbitrary file on disk so this bug is no worse in this regard.
Nevertheless it's a bug which should be fixed.
Closes: https://gitlab.com/libvirt/libvirt/-/work_items/904
Fixes: 0a3d177d9b
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an image example which specifies a 'backing_file' without
'backing_format' and the backing file has 'data_file'. This was obtained
by running a hacked qemu-img with bypassed requirement to specify backing
file format:
$ qemu-img create -f qcow2 -b datafile.qcow2 -u qcow2_datafile-auto.qcow2 1024
In the test directory.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuDomainChangeEjectableMedia() ran qemuDomainPrepareDiskSource() and
the surrounding image setup (backing chain detection, storage access,
managed PR) unconditionally. This makes no sense when ejecting the CD
media.
Wrap the image setup in a virStorageSourceIsEmpty() check, mirroring
qemuDomainAttachDeviceDiskLiveInternal(), and only revoke storage access
on rollback when it was actually granted, using a releaseSeclabel flag
as the attach path already does.
Signed-off-by: Mitsuru Kariya <Mitsuru.Kariya@oss.nttdata.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemuDomainRemoveDiskDevice() called
qemuBlockStorageSourceChainDetachPrepareBlockdev() unconditionally. A
CD-ROM with no media has an empty source, for which
virStorageSourceIsEmpty() returns true while virStorageSourceIsBacking()
still returns true, so the chain walk prepared a blockdev-del for a node
that was never created in QEMU. Detaching such a device produced an
internal error, either
"Failed to find node with node-name='libvirt-N-storage'" (when a prior
eject had left a stale node name in the source) or
"argument key 'node-name' must not have null value".
Guard the detach preparation with virStorageSourceIsEmpty(), as the
old-media detach in qemuDomainChangeMediaBlockdev() already does. The
following qemuBlockStorageSourceChainDetach() and access revoke are
already guarded by a non-NULL diskBackend, so an empty source is left
untouched.
Signed-off-by: Mitsuru Kariya <Mitsuru.Kariya@oss.nttdata.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Implementation is pretty similar to the one found in the qemu driver.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Move:
* qemuAgentDiskInfoFormatParams
* qemuAgentFSInfoFormatParams
* virDomainInterfaceFormatParams
from the qemu driver to hypervisor/qemu_agent.c so they could be reused
by the other drivers implementing virDomainGetGuestInfo() using the qemu
agent.
Also, rename virDomainInterfaceFormatParams() to
qemuAgentInterfaceFormatParams() to follow the common naming schema as
it's not really used outside of the qemu agent related code.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add enum and static-list completers for 'attach-disk' options
targetbus, type, cache, io, mode, and sourcetype, and reuse the
existing storage file format completer for subdriver.
Partially-fixes: https://gitlab.com/libvirt/libvirt/-/work_items/9
Signed-off-by: Radoslaw Smigielski <rsmigiel@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add a completer callback for local file paths used as command output,
where the target file may not exist yet.
Use it for 'dump', 'save', and 'blockcopy' commands, and fix
'screenshot' to use it instead of vshCompletePathLocalExisting.
Partially-fixes: https://gitlab.com/libvirt/libvirt/-/work_items/9
Signed-off-by: Radoslaw Smigielski <rsmigiel@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemuAutostartDomain() starts domains with conn=NULL as there is no
client connection during driver initialisation. Since the managed save
restore path of qemuDomainObjStart() was switched to
qemuDomainRestoreInternal(), which obtains the driver by dereferencing
conn->privateData, any domain with both a managed save image and the
autostart (or autostart-once) flag crashes virtqemud/libvirtd with
SIGSEGV on daemon startup.
The session daemon's auto-shutdown feature creates exactly this
combination on logout with a running VM (auto_shutdown_try_save saves
the domain and auto_shutdown_restore marks it autostart-once), so the
first daemon start of every subsequent boot segfaults and clients such
as GNOME Boxes fail with "Cannot recv data: Connection reset by peer",
showing an empty machine list.
Pass the driver as an explicit parameter, as qemuDomainObjRestore() did
before it was merged into qemuDomainRestoreInternal(), and keep @conn
only for use by the ACL check callbacks, which are not used in the
autostart code path.
Fixes: 0e2ab42778 ("qemu: driver: Merge 'qemuDomainRestoreInternal' and 'qemuDomainObjRestore'")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>