[PATCH] remote/stream-event: Fix a memory leak in
remoteStreamCallbackFree()
by liu.xuemei1＠zte.com.cn
From: Liu Song <liu.song13(a)zte.com.cn>
The ff callback is never called in remoteStreamCallbackFree() because
cbdata->cb can not be NULL. This causes a leak of 'cbdata->opaque'.
The leak can be reproduced by attaching and detaching to the console of
an VM using `virsh console`.
ASAN reports the leak stack as:
Direct leak of 288 byte(s) in 1 object(s) allocated from:
#0 0x7f6edf6ba0c7 in calloc (/lib64/libasan.so.8+0xba0c7)
#1 0x7f6edf5175b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x615b0)
#2 0x7f6ede6d0be3 in g_type_create_instance (/lib64/libgobject-2.0.so.0+0x3cbe3)
#3 0x7f6ede6b82cf in g_object_new_internal (/lib64/libgobject-2.0.so.0+0x242cf)
#4 0x7f6ede6b9877 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x25877)
#5 0x7f6ede6ba620 in g_object_new (/lib64/libgobject-2.0.so.0+0x26620)
#6 0x7f6edeb78138 in virObjectNew ../src/util/virobject.c:252
#7 0x7f6edeb7a78b in virObjectLockableNew ../src/util/virobject.c:274
#8 0x558251e427e1 in virConsoleNew ../tools/virsh-console.c:369
#9 0x558251e427e1 in virshRunConsole ../tools/virsh-console.c:427
Signed-off-by: Liu Song <liu.song13(a)zte.com.cn>
---
src/remote/remote_daemon_stream.c | 2 +-
src/remote/remote_driver.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c
index 453728a66b..a5032f9a43 100644
--- a/src/remote/remote_daemon_stream.c
+++ b/src/remote/remote_daemon_stream.c
@@ -437,13 +437,13 @@ int daemonAddClientStream(virNetServerClient *client,
return -1;
}
+ virObjectRef(client);
if (virStreamEventAddCallback(stream->st, 0,
daemonStreamEvent, client,
virObjectUnref) < 0)
return -1;
virObjectRef(client);
-
if ((stream->filterID = virNetServerClientAddFilter(client,
daemonStreamFilter,
stream)) < 0) {
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 2690c05267..9ac13469e9 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -5336,7 +5336,7 @@ static void remoteStreamCallbackFree(void *opaque)
{
struct remoteStreamCallbackData *cbdata = opaque;
- if (!cbdata->cb && cbdata->ff)
+ if (cbdata->ff)
(cbdata->ff)(cbdata->opaque);
virObjectUnref(cbdata->st);
--
2.27.0
1 hour, 1 minute
[libvirt PATCH] docs: clarify how to build without -Werror
by Ján Tomko
From: Ján Tomko <jtomko(a)redhat.com>
--werror does not accept any arguments for me and setting
git_werror was also needed to disable it with git.
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
docs/compiling.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/compiling.rst b/docs/compiling.rst
index 0a47a50569..06a2d53c3a 100644
--- a/docs/compiling.rst
+++ b/docs/compiling.rst
@@ -105,8 +105,8 @@ Notes:
~~~~~~
By default when the ``meson`` is run from within a GIT checkout, it will turn
-on -Werror for builds. This can be disabled with --werror=false, but this is
-not recommended.
+on -Werror for builds. This can be disabled with
+`-Dwerror=false -Dgit_werror=false`, but this is not recommended.
Please ensure that you have the appropriate minimal ``meson`` version installed
in your build environment. The minimal version for a specific package can be
--
2.49.0
7 hours, 19 minutes
Entering freeze for libvirt-11.5.0
by Jiri Denemark
I have just tagged v11.5.0-rc1 in the repository and pushed signed
tarballs to https://download.libvirt.org/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Jirka
8 hours, 7 minutes
[PATCH v2 00/13] qemu: use 'usb-bot' device to properly emulate USB cdroms
by Peter Krempa
Version 2 of this series includes changes I've requested in the review
and much more that I've learned during adaptation and testing:
- 'usb-bot' and 'usb-storage' are not ABI compatible for CDROMs
Migrating a guest from 'usb-bot'(with cdrom) to 'usb-storage' results
in I/O errors on reads with linux guest.
This required adding compatibility layer - exposing the model in -xml
and corresponding post-parse and migratable XML config
This patchset still tries as much as possible to use the 'usb-bot'
device for cdroms to fix the definition
- more tests
- keeping of 'usb-storage' support
- XML config and documentation
- cleanup of the code
The necessary logic is explained in the patches as comments.
Akihiko Odaki (2):
qemu_capabilities: Introduce QEMU_CAPS_DEVICE_USB_BOT
qemu: Replace usb-storage with usb-bot
Peter Krempa (11):
qemuhotplugtest: Use VIR_DOMAIN_DEF_PARSE_ABI_UPDATE for
virDomainDeviceDefParse
qemuxmlconftest: Test various combinations of config
qemusecuritytest: Use 'disk-usb-device' case instead of
'disk-cdrom-bus-other'
qemuxmlconftest: Drop 'disk-cdrom-bus-other'
qemuxmlconftest: Distribute testing of 'removable' disk property
qemuxmlconftest: Invoke "disk-usb-device" case also without
QEMU_CAPS_DEVICE_USB_BOT and with ABI_UPDATE
conf: introduce usb disk models 'usb-storage' and 'usb-bot'
qemu: Fill in model of 'usb' disks to preserve ABI compatibility
qemuBuildDeviceAddresDriveProps: Prepare for 'drive' address for
usb-bot disks
qemu: monitor: Introduce 'qemuMonitorSetUSBDiskAttached'
qemuxmlconftest: Prepare for proper testing in 'disk-cdrom-usb-empty'
docs/formatdomain.rst | 23 +++-
src/conf/domain_conf.c | 2 +
src/conf/domain_conf.h | 3 +
src/conf/schemas/domaincommon.rng | 2 +
src/qemu/qemu_alias.c | 20 ++-
src/qemu/qemu_capabilities.c | 7 +-
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_command.c | 101 ++++++++++++--
src/qemu/qemu_command.h | 5 +
src/qemu/qemu_domain.c | 21 +++
src/qemu/qemu_domain_address.c | 2 +
src/qemu/qemu_hotplug.c | 18 +++
src/qemu/qemu_monitor.c | 12 ++
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 20 +++
src/qemu/qemu_monitor_json.h | 5 +
src/qemu/qemu_postparse.c | 49 ++++++-
src/qemu/qemu_postparse.h | 4 +-
src/qemu/qemu_validate.c | 37 +++++-
tests/qemublocktest.c | 13 +-
.../caps_10.0.0_aarch64.xml | 1 +
.../caps_10.0.0_ppc64.xml | 1 +
.../caps_10.0.0_s390x.xml | 1 +
.../caps_10.0.0_x86_64+amdsev.xml | 1 +
.../caps_10.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 +
.../caps_6.2.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 +
.../caps_7.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 +
.../caps_7.1.0_x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 +
.../caps_7.2.0_x86_64+hvf.xml | 1 +
.../caps_7.2.0_x86_64.xml | 1 +
.../caps_8.0.0_x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 1 +
.../caps_8.1.0_x86_64.xml | 1 +
.../caps_8.2.0_aarch64.xml | 1 +
.../caps_8.2.0_armv7l.xml | 1 +
.../caps_8.2.0_loongarch64.xml | 1 +
.../qemucapabilitiesdata/caps_8.2.0_s390x.xml | 1 +
.../caps_8.2.0_x86_64.xml | 1 +
.../caps_9.0.0_x86_64.xml | 1 +
.../caps_9.1.0_riscv64.xml | 1 +
.../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 1 +
.../caps_9.1.0_x86_64.xml | 1 +
.../caps_9.2.0_aarch64+hvf.xml | 1 +
.../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 1 +
.../caps_9.2.0_x86_64+amdsev.xml | 1 +
.../caps_9.2.0_x86_64.xml | 1 +
tests/qemuhotplugtest.c | 8 +-
.../qemuhotplug-base-live+cdrom-usb.xml | 2 +-
.../qemuhotplug-base-live+disk-usb.xml | 2 +-
tests/qemusecuritytest.c | 2 +-
.../disk-cache.x86_64-latest.xml | 2 +-
.../qemuxmlconfdata/disk-cdrom-bus-other.xml | 30 -----
...m-usb-empty.x86_64-latest.abi-update.args} | 4 +-
...om-usb-empty.x86_64-latest.abi-update.xml} | 6 +-
.../disk-device-removable.x86_64-latest.args | 40 ------
.../qemuxmlconfdata/disk-device-removable.xml | 32 -----
.../disk-scsi.x86_64-latest.args | 2 +-
tests/qemuxmlconfdata/disk-scsi.xml | 2 +-
.../disk-usb-device-model.x86_64-latest.args | 48 +++++++
...> disk-usb-device-model.x86_64-latest.xml} | 46 ++++---
.../qemuxmlconfdata/disk-usb-device-model.xml | 46 +++++++
...est.QEMU_CAPS_DEVICE_USB_BOT-disabled.args | 59 +++++++++
...test.QEMU_CAPS_DEVICE_USB_BOT-disabled.xml | 107 +++++++++++++++
...ate.QEMU_CAPS_DEVICE_USB_BOT-disabled.args | 59 +++++++++
...date.QEMU_CAPS_DEVICE_USB_BOT-disabled.xml | 125 ++++++++++++++++++
...k-usb-device.x86_64-latest.abi-update.args | 63 +++++++++
...sk-usb-device.x86_64-latest.abi-update.xml | 125 ++++++++++++++++++
.../disk-usb-device.x86_64-latest.args | 30 ++++-
.../disk-usb-device.x86_64-latest.xml | 82 ++++++++++--
tests/qemuxmlconfdata/disk-usb-device.xml | 66 ++++++++-
tests/qemuxmlconftest.c | 16 ++-
75 files changed, 1197 insertions(+), 187 deletions(-)
delete mode 100644 tests/qemuxmlconfdata/disk-cdrom-bus-other.xml
rename tests/qemuxmlconfdata/{disk-cdrom-bus-other.x86_64-latest.args => disk-cdrom-usb-empty.x86_64-latest.abi-update.args} (84%)
rename tests/qemuxmlconfdata/{disk-cdrom-bus-other.x86_64-latest.xml => disk-cdrom-usb-empty.x86_64-latest.abi-update.xml} (89%)
delete mode 100644 tests/qemuxmlconfdata/disk-device-removable.x86_64-latest.args
delete mode 100644 tests/qemuxmlconfdata/disk-device-removable.xml
create mode 100644 tests/qemuxmlconfdata/disk-usb-device-model.x86_64-latest.args
rename tests/qemuxmlconfdata/{disk-device-removable.x86_64-latest.xml => disk-usb-device-model.x86_64-latest.xml} (56%)
create mode 100644 tests/qemuxmlconfdata/disk-usb-device-model.xml
create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.QEMU_CAPS_DEVICE_USB_BOT-disabled.args
create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.QEMU_CAPS_DEVICE_USB_BOT-disabled.xml
create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.abi-update.QEMU_CAPS_DEVICE_USB_BOT-disabled.args
create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.abi-update.QEMU_CAPS_DEVICE_USB_BOT-disabled.xml
create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.abi-update.args
create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.abi-update.xml
--
2.49.0
8 hours, 46 minutes
Re: [PATCH v2 09/10] net: Add passt network backend
by Markus Armbruster
Laurent Vivier <lvivier(a)redhat.com> writes:
> On 24/06/2025 10:16, Markus Armbruster wrote:
>> Laurent Vivier <lvivier(a)redhat.com> writes:
>>
>>> This commit introduces support for passt as a new network backend.
>>> passt is an unprivileged, user-mode networking solution that provides
>>> connectivity for virtual machines by launching an external helper process.
>>>
>>> The implementation reuses the generic stream data handling logic. It
>>> launches the passt binary using GSubprocess, passing it a file
>>> descriptor from a socketpair() for communication. QEMU connects to
>>> the other end of the socket pair to establish the network data stream.
>>>
>>> The PID of the passt daemon is tracked via a temporary file to
>>> ensure it is terminated when QEMU exits.
>>>
>>> Signed-off-by: Laurent Vivier <lvivier(a)redhat.com>
>>
>> [...]
>>
>>> diff --git a/qapi/net.json b/qapi/net.json
>>> index 97ea1839813b..76d7654414f7 100644
>>> --- a/qapi/net.json
>>> +++ b/qapi/net.json
>>> @@ -112,6 +112,125 @@
>>> 'data': {
>>> 'str': 'str' } }
>>>
>>> +##
>>> +# @NetDevPasstOptions:
>>> +#
>>> +# Unprivileged user-mode network connectivity using passt
>>> +#
>>> +# @path: path to passt binary
>>
>> I'd prefer a more descriptive name.
>>
>> Elsewhere in this file, we refer to programs like this:
>>
>> # @script: script to initialize the interface
>> #
>> # @downscript: script to shut down the interface
>>
>> passt isn't a script, of course.
>>
>> I don't know, perhaps
>>
>> # @passt-filename: the passt program to run.
>>
>> or even
>>
>> # @passt: Filename of the passt program to run.
>>
>>> +#
>>> +# @quiet: don't print informational messages
>>
>> What does the printing? A peek at the code I snipped suggests this flag
>> is passed to the passt binary as --quiet. Correct?
>>
>>> +#
>>> +# @debug: be verbose
>>> +#
>>> +# @trace: extra verbose
>>
>> Likewise for these two.
>>
>>> +#
>>> +# @vhost-user: enable vhost-user
[...]
>>> +# @udp-ports: UDP ports to forward
>>
>> Is there anything in this struct that configures qemu-system-FOO itself,
>> i.e. isn't just passed to passt?
>>
>
> Yes, all parameters are just passed to passt.
>
> Do you think it's better not to add all these parameters to netdev backend but only one
> generic containing the passt command line parameters?
I'm not sure.
Thoughts from libvirt's perspective?
10 hours, 21 minutes
[PATCH] qemu_monitor_json: Use proper initializer in qemuMonitorJSONGetBlockInfo()
by Michal Privoznik
From: Michal Privoznik <mprivozn(a)redhat.com>
Inside of qemuMonitorJSONGetBlockInfo() there's a for loop in
which a variable of struct qemuDomainDiskInfo type is declared
and initialized as { false }. This works only because stdbool.h
declares 'false' as a macro, so preprocessor expands initializer
to proper form of { 0 }.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_monitor_json.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index a6fb2a2013..2de68d6518 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -2206,7 +2206,7 @@ int qemuMonitorJSONGetBlockInfo(qemuMonitor *mon,
for (i = 0; i < virJSONValueArraySize(devices); i++) {
virJSONValue *dev;
virJSONValue *image;
- struct qemuDomainDiskInfo info = { false };
+ struct qemuDomainDiskInfo info = { 0 };
const char *thisdev;
const char *status;
const char *qdev;
--
2.49.0
10 hours, 40 minutes
[PATCH v2] util: workaround libxml2 lack of thread safe initialization
by Daniel P. Berrangé
From: Daniel P. Berrangé <berrange(a)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
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
Changed in v3:
- Drop xmlInitializeCatalog - I misread the code wrt
thread safety - it has a sufficiently protective mutex
- Cope with return type change for xmlSchemaInitTypes
in libxml >= 2.11.0
src/util/virxml.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/src/util/virxml.c b/src/util/virxml.c
index 9d46e5f32f..c851d6f407 100644
--- a/src/util/virxml.c
+++ b/src/util/virxml.c
@@ -26,6 +26,8 @@
#include <libxml/xmlsave.h>
#include <libxml/xpathInternals.h>
+#include <libxml/xmlschemastypes.h>
+#include <libxml/catalog.h>
#include "virerror.h"
#include "virxml.h"
@@ -35,6 +37,7 @@
#include "virstring.h"
#include "virutil.h"
#include "viruuid.h"
+#include "virthread.h"
#include "configmake.h"
#define VIR_FROM_THIS VIR_FROM_XML
@@ -50,6 +53,28 @@ struct virParserData {
};
+static int
+virXMLSchemaOnceInit(void)
+{
+#if LIBXML_VERSION >= 21100
+ if (xmlSchemaInitTypes() < 0) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Unable to initialize libxml2 schema types"));
+ return -1;
+ }
+#else
+ xmlSchemaInitTypes();
+#endif
+ if (xmlRelaxNGInitTypes() < 0) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Unable to initialize libxml2 RelaxNG data"));
+ return -1;
+ }
+ return 0;
+}
+
+VIR_ONCE_GLOBAL_INIT(virXMLSchema);
+
static xmlXPathContextPtr
virXMLXPathContextNew(xmlDocPtr xml)
{
@@ -1603,6 +1628,9 @@ virXMLValidatorInit(const char *schemafile)
{
g_autoptr(virXMLValidator) validator = NULL;
+ if (virXMLSchemaInitialize() < 0)
+ return NULL;
+
validator = g_new0(virXMLValidator, 1);
validator->schemafile = g_strdup(schemafile);
--
2.49.0
1 day, 2 hours
Re: virsh migrate fails when --copy-storage-all option is given!
by Anushree Mathur
CC: libvirt devel list
Hi Kevin/Peter,
Thank you so much for addressing this issue. I tried out few more things and
here is my analysis:
Even when I removed the readonly option from guest xml I was still seeing the
issue in migration,In the qemu-commandline I could still see auto-read-only
option being set as true by default.
Then I tried giving the auto-read-only as false in the guest xml with
qemu-commandline param, it was actually getting set to false and the migration
worked!
Steps I tried:
1) Started the guest with adding the snippet in the guest xml with parameters
as:
<qemu:commandline>
<qemu:arg value='-blockdev'/>
<qemu:arg value='driver=file,filename=/disk_nfs/nfs/migrate_root.qcow2,node-name=drivefile,auto-read-only=false'/>
<qemu:arg value='-blockdev'/>
<qemu:arg value='driver=qcow2,file=drivefile,node-name=drive0'/>
<qemu:arg value='-device'/>
<qemu:arg value='virtio-blk-pci,drive=drive0,id=virtio-disk0,bus=pci.0,addr=0x5'/>
</qemu:commandline>
2) Started the migration and it worked.
Could anyone please clarify from libvirt side what is the change required?
Thanks,
Anushree-Mathur
On 04/06/25 6:57 PM, Peter Krempa wrote:
> On Wed, Jun 04, 2025 at 14:41:54 +0200, Kevin Wolf wrote:
>> Am 28.05.2025 um 17:34 hat Peter Xu geschrieben:
>>> Copy Kevin.
>>>
>>> On Wed, May 28, 2025 at 07:21:12PM +0530, Anushree Mathur wrote:
>>>> Hi all,
>>>>
>>>>
>>>> When I am trying to migrate the guest from host1 to host2 with the command
>>>> line as follows:
>>>>
>>>> date;virsh migrate --live --domain guest1 qemu+ssh://dest/system --verbose
>>>> --undefinesource --persistent --auto-converge --postcopy
>>>> --copy-storage-all;date
>>>>
>>>> and it fails with the following error message-
>>>>
>>>> error: internal error: unable to execute QEMU command 'block-export-add':
>>>> Block node is read-only
>>>>
>>>> HOST ENV:
>>>>
>>>> qemu : QEMU emulator version 9.2.2
>>>> libvirt : libvirtd (libvirt) 11.1.0
>>>> Seen with upstream qemu also
>>>>
>>>> Steps to reproduce:
>>>> 1) Start the guest1
>>>> 2) Migrate it with the command as
>>>>
>>>> date;virsh migrate --live --domain guest1 qemu+ssh://dest/system --verbose
>>>> --undefinesource --persistent --auto-converge --postcopy
>>>> --copy-storage-all;date
>>>>
>>>> 3) It fails as follows:
>>>> error: internal error: unable to execute QEMU command 'block-export-add':
>>>> Block node is read-only
>> I assume this is about an inactive block node. Probably on the
>> destination, but that's not clear to me from the error message.
> Yes this would be on the destination. Libvirt exports the nodes on
> destination, source connects and does the blockjob.
>
> The destination side is configured the same way as the source side so
> if the source disk is configured as read-write the destination should be
> as well
>
>>>> Things I analyzed-
>>>> 1) This issue is not happening if I give --unsafe option in the virsh
>>>> migrate command
> This is weird; this shouldn't have any impact.
>
>> What does this translate to on the QEMU command line?
>>
>>>> 2) O/P of qemu-monitor command also shows ro as false
>>>>
>>>> virsh qemu-monitor-command guest1 --pretty --cmd '{ "execute": "query-block"
> it'd be impossible to execute this on the guest due to timing; you'll
> need to collect libvirt debug logs to do that:
>
> https://www.libvirt.org/kbase/debuglogs.html#tl-dr-enable-debug-logs-for-...
>
> I also thing this should be eventually filed in a
>
>>>> }'
>>>> {
>>>> "return": [
>>>> {
>>>> "io-status": "ok",
>>>> "device": "",
>>>> "locked": false,
>>>> "removable": false,
>>>> "inserted": {
>>>> "iops_rd": 0,
>>>> "detect_zeroes": "off",
>>>> "image": {
>>>> "virtual-size": 21474836480,
>>>> "filename": "/home/Anu/guest_anu.qcow2",
>>>> "cluster-size": 65536,
>>>> "format": "qcow2",
>>>> "actual-size": 5226561536,
>>>> "format-specific": {
>>>> "type": "qcow2",
>>>> "data": {
>>>> "compat": "1.1",
>>>> "compression-type": "zlib",
>>>> "lazy-refcounts": false,
>>>> "refcount-bits": 16,
>>>> "corrupt": false,
>>>> "extended-l2": false
>>>> }
>>>> },
>>>> "dirty-flag": false
>>>> },
>>>> "iops_wr": 0,
>>>> "ro": false,
>>>> "node-name": "libvirt-1-format",
>>>> "backing_file_depth": 0,
>>>> "drv": "qcow2",
>>>> "iops": 0,
>>>> "bps_wr": 0,
>>>> "write_threshold": 0,
>>>> "encrypted": false,
>>>> "bps": 0,
>>>> "bps_rd": 0,
>>>> "cache": {
>>>> "no-flush": false,
>>>> "direct": false,
>>>> "writeback": true
>>>> },
>>>> "file": "/home/Anu/guest_anu.qcow2"
>>>> },
>>>> "qdev": "/machine/peripheral/virtio-disk0/virtio-backend",
>>>> "type": "unknown"
>>>> }
>>>> ],
>>>> "id": "libvirt-26"
>>>> }
>> I assume this is still from the source where the image is still active.
> Yes; on the destination the process wouldn't be around long enough to
> call 'virsh qemu-monitor-command'
>
>> Also it doesn't contain the "active" field yet that was recently
>> introduced, which could show something about this. I believe you would
>> still get "read-only": false for an inactive image if it's supposed to
>> be read-write after the migration completes.
>>
>>>> 3) Guest doesn't have any readonly
>>>>
>>>> virsh dumpxml guest1 | grep readonly
>>>>
>>>> 4) Tried giving the proper permissions also
>>>>
>>>> -rwxrwxrwx. 1 qemu qemu 4.9G Apr 28 15:06 guest_anu.qcow
> Is this on the destination? did you pre-create it yourself? otherwise
> libvirt is pre-creating that image for-non-shared-storage migration
> (--copy-storage-all) which should have proper permissions when it's
> created
>
>>>> 5) Checked for the permission of the pool also that is also proper!
>>>>
>>>> 6) Found 1 older bug similar to this, pasting the link for reference:
>>>>
>>>>
>>>> https://patchwork.kernel.org/project/qemu-devel/patch/20170811164854.GG41...
>> What's happening in detail is more of a virsh/libvirt question. CCing
>> Peter Krempa, he might have an idea.
> Please collect the debug log; at least from the destination side of
> migration. That should show how the VM is prepared and qemu invoked.
>
1 day, 2 hours
[libvirt PATCH v2 REBASED 0/7] qemu: introduce amd-iommu support
by Ján Tomko
Ján Tomko (7):
qemu: introduce QEMU_CAPS_AMD_IOMMU
qemu: introduce QEMU_CAPS_PCI_ID
qemu: add IOMMU model amd
docs: formatdomain: document intel-only IOMMU attributes
conf: add passthrough and xtsup attributes for IOMMU
conf: reject some attributes not applicable to intel IOMMU
qemu: format pt and xstup on the command line
docs/formatdomain.rst | 22 +++-
src/conf/domain_conf.c | 31 +++++
src/conf/domain_conf.h | 3 +
src/conf/domain_validate.c | 22 ++++
src/conf/schemas/domaincommon.rng | 11 ++
src/qemu/qemu_capabilities.c | 12 ++
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_command.c | 30 +++++
src/qemu/qemu_domain_address.c | 4 +
src/qemu/qemu_validate.c | 22 ++++
.../caps_10.0.0_x86_64+amdsev.replies | 102 +++++++++++------
.../caps_10.0.0_x86_64+amdsev.xml | 1 +
.../caps_10.0.0_x86_64.replies | 106 ++++++++++++------
.../caps_10.0.0_x86_64.xml | 2 +
.../caps_6.2.0_x86_64.replies | 102 +++++++++++------
.../caps_6.2.0_x86_64.xml | 1 +
.../caps_7.0.0_x86_64.replies | 80 +++++++------
.../caps_7.0.0_x86_64.xml | 1 +
.../caps_7.1.0_x86_64.replies | 102 +++++++++++------
.../caps_7.1.0_x86_64.xml | 1 +
.../caps_7.2.0_x86_64+hvf.replies | 102 +++++++++++------
.../caps_7.2.0_x86_64+hvf.xml | 1 +
.../caps_7.2.0_x86_64.replies | 102 +++++++++++------
.../caps_7.2.0_x86_64.xml | 1 +
.../caps_8.0.0_x86_64.replies | 80 +++++++------
.../caps_8.0.0_x86_64.xml | 1 +
.../caps_8.1.0_x86_64.replies | 102 +++++++++++------
.../caps_8.1.0_x86_64.xml | 1 +
.../caps_8.2.0_x86_64.replies | 102 +++++++++++------
.../caps_8.2.0_x86_64.xml | 1 +
.../caps_9.0.0_x86_64.replies | 80 +++++++------
.../caps_9.0.0_x86_64.xml | 1 +
.../caps_9.1.0_x86_64.replies | 102 +++++++++++------
.../caps_9.1.0_x86_64.xml | 1 +
.../caps_9.2.0_x86_64+amdsev.replies | 102 +++++++++++------
.../caps_9.2.0_x86_64+amdsev.xml | 1 +
.../caps_9.2.0_x86_64.replies | 102 +++++++++++------
.../caps_9.2.0_x86_64.xml | 1 +
.../amd-iommu.x86_64-latest.args | 35 ++++++
.../amd-iommu.x86_64-latest.xml | 1 +
tests/qemuxmlconfdata/amd-iommu.xml | 39 +++++++
tests/qemuxmlconftest.c | 2 +
42 files changed, 1165 insertions(+), 454 deletions(-)
create mode 100644 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.args
create mode 120000 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/amd-iommu.xml
--
2.49.0
1 day, 7 hours
[PATCH 0/4] USB hostdev: allow addressing by port
by Maximilian Martin
This resubmission splits up the previous patch into multiple patches and
incorporates review comments from Michal Prívozník.
Currently, only vendor/product and bus/device matching are supported for USB host
devices. Neither of these provide a stable and persistent way of assigning a guest
a specific host device. Vendor/product can be ambiguous. Device numbers change on
every enumeration.
This patch adds a bus/port matching, which allows a specific port on the host to be
specified using the dotted notation found in Linux's "devpath" sysfs attribute.
This patch is based on the previous work of Thomas Hebb: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7...
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/513
Signed-off-by: Maximilian Martin <maximilian_martin(a)gmx.de>
Maximilian Martin (4):
virusb test data: add devpath files for port addressing
domain_conf, virhostdev, virusb, virusb test: add bus/port matching
schema: add USB port attribute
docs: add description for USB port matching
docs/formatdomain.rst | 29 ++--
src/conf/domain_conf.c | 69 +++++++-
src/conf/domain_conf.h | 1 +
src/conf/schemas/domaincommon.rng | 11 +-
src/hypervisor/virhostdev.c | 131 +++++++++------
src/libvirt_private.syms | 2 -
src/util/virusb.c | 156 ++++++------------
src/util/virusb.h | 32 ++--
tests/virusbtest.c | 149 ++++++++++++-----
.../sys_bus_usb/devices/1-1.5.3.1/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.3.3/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.3/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.4/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.5/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.6/devpath | 1 +
.../sys_bus_usb/devices/1-1.5/devpath | 1 +
.../sys_bus_usb/devices/1-1.6/devpath | 1 +
.../sys_bus_usb/devices/1-1/devpath | 1 +
.../sys_bus_usb/devices/2-1.2/devpath | 1 +
.../sys_bus_usb/devices/2-1/devpath | 1 +
.../sys_bus_usb/devices/usb1/devpath | 1 +
.../sys_bus_usb/devices/usb2/devpath | 1 +
.../sys_bus_usb/devices/usb3/devpath | 1 +
.../sys_bus_usb/devices/usb4/devpath | 1 +
24 files changed, 351 insertions(+), 244 deletions(-)
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.4/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.5/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.6/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.6/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1.2/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb2/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb4/devpath
--
2.39.5
1 day, 8 hours
