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: Jiri Denemark <jdenemar@redhat.com>
Add a test case for explicitly selected USB disk models.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
usb-storage is a compound device that automatically creates a USB mass
storage device and a SCSI device as its backend. Unfortunately it lacks
some configuration options that are usually present with a SCSI device,
and cannot represent CD-ROM in particular.
Replace usb-storage with usb-bot, which can be combined with a manually
created SCSI device. libvirt will configure the SCSI device in a way
identical with how QEMU does for usb-storage except that now it respects
a configuration option to represent CD-ROM.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/368
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Modify the validation of empty cdroms to trigger only for
VIR_DOMAIN_DISK_MODEL_USB_STORAGE as with 'usb-bot' we can properly
emulate a cdrom.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The helper sets the 'attached' property of the 'usb-bot' device to true,
which will be used on the hotplug code path.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
While the 'usb-storage' based disks use the USB address directly, with
'usb-bot' the USB address is on the "controller" part of the device and
the 'scsi-hd/cd' device will use a 'drive' address from qemu's PoV.
Since we do not want to expose the 'usb-bot' as explicit controller
to preserve compatibility with existing configs we plan to upgrade
implement the formatter for 'drive' address when the "diskbus" property
is VIR_DOMAIN_DISK_BUS_USB.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
While 'usb-bot' and 'usb-storage' are ABI and migration compatible for
disks it's not the case for cdroms. When migrating from a new config
using 'usb-bot' to an older daemon which would use 'usb-storage' the
guest os will get I/O errors.
Thus we must properly fill in models for 'usb' disks so that cdroms can
be handled properly.
When parsing XML fill in the models and drop the appropriate models when
formatting migratable XML.
The logic is explained in comments in the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Historically libvirt specified 'usb-storage' as driver for USB disks.
This though combined with '-blockdev' doesn't properly configure the
device to look like CDROM for <disk type='cdrom'>.
'usb-bot' acts like a controler and allows explicitly connecting a
-device to it.
In qemu the devices share implementation so they are effectively
identical and can be used interchangably. There is a difference in how
the storage device itself (the SCSI part) looks when configured properly
as CDROM which is unfortunately not compatible/interchangable.
As this is effectively a bugfix we'll be fixing the behaviour for the
default configuration. The possibility to explicitly set the model is
added as a possibility for working around possible problems if they'd
appear.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The QEMU_CAPS_DEVICE_USB_BOT device can be compiled out but
realistically it makes no sense to do it thus also makes no sense to
have another variant of input data for it.
Add another invocation of "disk-usb-device" clearing QEMU_CAPS_DEVICE_USB_BOT
to show the fallback code paths.
Also add "ABI_UPDATE" version for the two cases above as the ABI of
usb-bot cdrom is not migration-compatible and we'll be wanting to update
to the fixed configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
usb-bot is supported by all supported QEMU versions; it is present since
1.4.0 and libvirt supports 4.2.0 or later.
Add a capability just in case USB_STORAGE_BOT is disabled when building
QEMU.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The 'removable' property is tested for 'usb' and 'scsi' disks. The test
case for 'usb' disks already has another test case for this, so add
testing of 'removable' SCSI disks into the 'disk-scsi' case and remove
the 'disk-device-removable' case completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The test case is now redundant since 'disk-usb-device' case also tests
all cdrom configurations. Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add multiple USB disks to the definition testing a matrix of 'disk' and
'cdrom' <disk> elements with user-aliases, 'serial' and 'removable'
properties configured.
This patch also removes the 'ide' disk which is not related to what
we're testing here.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The qemu hotplug code parses the device with ABI updates enabled so
qemuhotplugtest ought to do the same.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The main XML parser code global initializer historically had a mutex
protecting it, and more recently uses a pthread_once. The RelaxNG
code, however, relies on two other global initializers that are
not thread safe, just relying on setting an integer "initialized"
flag.
Calling the relevant initializers from libvirt in a protected global
initializer will protect libvirt's own concurrent usage, however, it
cannot protect against other libraries loaded in process that might
be using libxml2's schema code. Fortunately:
* The chances of other loaded non-libvirt code using libxml is
relatively low
* The chances of other loaded non-libvirt code using the schema
validation / catalog functionality inside libxml is even
lower
* The chances of both libvirt and the non-libvirt usage having
their *1st* usage of libxml2 be concurrent is tiny
IOW, in practice, although our solution doesn't fully fix the thread
safety, it is good enough.
libxml2 should none the less still be fixed to make its global
initializers be thread safe without special actions by its API
consumers[1].
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/788
[1] https://gitlab.gnome.org/GNOME/libxml2/-/merge_requests/326
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduced by QEMU commit f864a3235ea1d1d714b3cde2d9a810ea6344a7b5
the presence of this attribute allows libvirt to specify the alias
of the AMDVI-PCI device explicitly.
(It was implicit before the introduction of this attribute)
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Check for the presence of the amd-iommu device, so we can conditionalize
probing for its properties.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Shifting bits into the sign bit is undefined behaviour in C although
both gcc and clang handle it as expected.
Since the value is used as unsigned convert it to unsigned int. For code
readability use 'if' statement instead of a ternary.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/785
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When a domain is being started, seclabels are generated for it.
This is handled in virSecurityManagerGenLabel() which can either
find pre-existing seclabel in domain def or generate a new one.
At any rate, domainGenSecurityLabel() callback is called and if
it fails then the seclabel is removed from domain definition
using VIR_DELETE_ELEMENT(). While this shrinks down the seclabels
array, it does not free individual item. It has to be freed
manually.
80 bytes in 2 blocks are definitely lost in loss record 1,359 of 1,876
at 0x484CEF3: calloc (vg_replace_malloc.c:1675)
by 0x4F19B29: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8200.5)
by 0x49E4953: virSecurityLabelDefNew (virseclabel.c:59)
by 0x4BDE0A4: virSecurityManagerGenLabel (security_manager.c:638)
by 0xBA029B7: qemuProcessPrepareDomain (qemu_process.c:6760)
by 0xBA07DF2: qemuProcessStart (qemu_process.c:8369)
by 0xB93DAC0: qemuDomainObjStart (qemu_driver.c:6371)
by 0xB93DE08: qemuDomainCreateWithFlags (qemu_driver.c:6420)
by 0xB93DE86: qemuDomainCreate (qemu_driver.c:6438)
by 0x4CECEA8: virDomainCreate (libvirt-domain.c:7142)
Now, you might think this may lead to a double free, because
@seclabel is freed under the 'cleanup' label (if @generated is
true). But if @generated is true, then just before calling the
callback there's VIR_APPEND_ELEMENT() which clears @seclabel out
turning the free under 'cleanup' label into a NOP.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In my previous commit of v11.0.0-rc1~115 I've made QEMU driver
implementation for virDomainGetXMLDesc() (qemuDomainGetXMLDesc())
acquire QERY job. See its commit message for more info. But this
unfortunately broke apps witch fetch domain XML for incoming
migration (like virt-manager). The reason is that for incoming
migration the VIR_ASYNC_JOB_MIGRATION_IN async job is set, but
the mask of allowed synchronous jobs is empty (because QEMU can't
talk on monitor really). This makes virDomainObjBeginJob() fail
which in turn makes qemuDomainGetXMLDesc() fail too.
It makes sense for qemuDomainGetXMLDesc() to acquire the job
(e.g. so that it's coherent with another thread that might be in
the middle of a MODIFY job). But failure to dump XML may be
treated as broken daemon (e.g. virt-manager does so).
Therefore, still try to acquire the QUERY job (if job mask
permits it) but, do not treat failure as an error.
Fixes: 6cc93bf288
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2369243
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>