[libvirt PATCH] kbase: Shorten "less verbose QEMU logging" example
by Andrea Bolognani
Rationale for the changes:
* util.dbus produces very little logging, so it doesn't really
make sense to filter it out;
* util.udev doesn't exist;
* access can be filtered out entirely, as nothing very
interesting is produced by the only other component in the
same package (access.accessdriverpolkit).
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/kbase/debuglogs.rst | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/docs/kbase/debuglogs.rst b/docs/kbase/debuglogs.rst
index 7945cf8bed..fed998efd8 100644
--- a/docs/kbase/debuglogs.rst
+++ b/docs/kbase/debuglogs.rst
@@ -178,13 +178,12 @@ Less verbose logging for QEMU VMs
Some subsystems are very noisy and usually not the culprit of the problems. They
can be silenced individually for a less verbose log while still logging
-everything else. Usual suspects are the JSON code, udev, authentication and such.
+everything else. Usual suspects are the JSON code, RPC, authentication and such.
A permissive filter is good for development use cases.
::
- 3:remote 4:event 3:util.json 3:util.object 3:util.dbus 3:util.udev 3:node_device 3:rpc 3:access.accessmanager 3:util.netlink 1:*
-
+ 3:remote 4:event 3:util.json 3:util.object 3:util.netlink 3:node_device 3:rpc 3:access 1:*
Minimalistic QEMU QMP monitor logging
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.26.2
4 years, 1 month
[PATCH 0/2] virnetdevopenvswitch: Get names for dpdkvhostuserclient too
by Michal Privoznik
The first patch fixes the actual problem, the second is just a
cleanup I've came up with whilst looking at the code.
Michal Prívozník (2):
virnetdevopenvswitch: Get names for dpdkvhostuserclient too
virnetdevopenvswitch: Simplify OVS_VSCTL cmd creation
src/qemu/qemu_command.c | 1 +
src/qemu/qemu_hotplug.c | 1 +
src/util/virnetdevopenvswitch.c | 92 +++++++++++++++++++--------------
src/util/virnetdevopenvswitch.h | 1 +
tests/qemuxml2argvmock.c | 1 +
5 files changed, 56 insertions(+), 40 deletions(-)
--
2.26.2
4 years, 1 month
[libvirt PATCH] docs: compiling.html: pass -d to xz to decompress
by Daniel P. Berrangé
From: Jonathan Watt <jwatt(a)jwatt.org>
tar on macOS recognizes XZ compression automatically, but that is
not the case for GNU tar (1.32 at least). On Fedora 33 the current
instructions result in the following error:
$ xz -c libvirt-6.9.0.tar.xz | tar xvf -
tar: Archive is compressed. Use -J option
tar: Error is not recoverable: exiting now
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
Signed-off-by: Jonathan Watt <jwatt(a)jwatt.org>
---
Pushed as a trivial patch from gitlab
docs/compiling.html.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/compiling.html.in b/docs/compiling.html.in
index c898d16313..c2c9d9f0ed 100644
--- a/docs/compiling.html.in
+++ b/docs/compiling.html.in
@@ -14,7 +14,7 @@
</p>
<pre>
-$ xz -c libvirt-x.x.x.tar.xz | tar xvf -
+$ xz -dc libvirt-x.x.x.tar.xz | tar xvf -
$ cd libvirt-x.x.x
$ meson build</pre>
--
2.28.0
4 years, 1 month
[PATCH 0/6] qemu: Enable client TLS certificate validation by default for chardev, migration, and backup servers
by Peter Krempa
See patches 6 for a explanation.
Peter Krempa (6):
qemu: conf: Allow individual control of default value for
*_tls_x509_verify
qemu: conf: Clarify default of "vnc_tls_x509_verify"
qemu: conf: Enable 'chardev_tls_x509_verify' by default
qemu: conf: Enable 'migrate_tls_x509_verify' by default
qemu: conf: Enable 'backup_tls_x509_verify' by default
NEWS: Mention change of default for TLS certificate verification
NEWS.rst | 11 +++++++++++
src/qemu/qemu.conf | 18 ++++++++++++++----
src/qemu/qemu_conf.c | 22 ++++++++++++++--------
src/qemu/qemu_conf.h | 1 +
4 files changed, 40 insertions(+), 12 deletions(-)
--
2.28.0
4 years, 1 month
Re: [PATCH] Added attach-disk parameters for network disk support
by Peter Krempa
On Thu, Nov 12, 2020 at 15:15:27 -0600, Ryan Gahagan wrote:
> Hey Peter,
Hi Ryan,
firstly I'd like to ask you to keep the conversation on-list. (use
reply-all all the time). This ensures that the response is public and
also other people can jump in and respont. At the very least it can be
used for future reference.
I'll be re-adding the mailing list in this response.
Also please avoid top-posting in techincal lists. It's always best to
respond inline at the proper context that is being discussed.
> Sorry about all the issues with our commit, we're new to this and trying to
> make our first contribution to this repo. We had a couple questions over
> your feedback and wanted to run them by you before making another request.
Sure thing, you can always ask on the mailing list even without patches.
> In the original code, the --source parameter is marked as required but okay
> to be empty. If the string is empty, then we think the parameter read in by
> vshCommandOptStringReq would be NULL, in which case no <source> tag would
> be generated at all. If this is the case, then why is --source required in
> the first place? We see that --source-name is mutually exclusive witha
That's a quirk of it being a positional argument (VSH_OT_DATA). A
positional argument is mandatory.
> --source, but is it also okay to be empty? For example, in the issue
> <https://gitlab.com/libvirt/libvirt/-/issues/16> this patch was based on,
> there's an example XML which has a <source> with neither a file nor a name.
> Is this example incorrect, or is it fine to have neither and only have a
> protocol?
That is correct for example with the NBD protocol where a missing name
actually means the default unnamed export.
The thing is that we can't really change --source to be something else
than VSH_OT_DATA since it would change the semantics of the virsh
command.
You probably will need to use it also for the 'name' attribute and
switch the name according to the presence of the 'protocol'
attribute/option.
> When it comes to making these mutually exclusive, we also were confused on
> what flags to give them. Would it be proper behavior to give them both no
> flags or only the VSH_OFLAG_EMPTY_OK flag and then check that one is
> defined in the cmdAttachDisk method (using VSH_EXCLUSIVE_OPTIONS_VAR) and
> error there instead?
Those are two separate things. If it makes sense for a flag to be
specified but empty and it impacts behaviour then you need to use
VSH_OFLAG_EMPTY_OK.
Any non-positional arguments (those which need --) can be made optional.
On the other hand that does not say anything about how they can or can't
be combined with other options and thus you need to declare that in the
code.
> If the user provides an empty source without any protocol, but provides
> --source-host-* parameters, what should be generated instead? Would this
This should be an error. --source-host must require the use of
--source-protocol
> cause an error, would it generate an in-line <host> tag, or would it
> generate a completely empty <source> tag followed by the host information?
The protocol option flag should be mandatory if you want to use the
host/socket.
>
> -Ryan Gahagan
>
> On Thu, Nov 12, 2020 at 2:57 AM Peter Krempa <pkrempa(a)redhat.com> wrote:
>
> > On Wed, Nov 11, 2020 at 17:00:51 -0600, Ryan Gahagan wrote:
> > > Related issue: https://gitlab.com/libvirt/libvirt/-/issues/16
> > > Added in support for the following parameters in attach-disk:
> > > --source-name
> > > --source-protocol
> > > --source-host-name
> > > --source-host-socket
> > > --source-host-transport
Please trim parts of the message that are no longer relevant.
[...]
4 years, 1 month
[PATCH] viridentitytest: Run more frequently
by Michal Privoznik
The viridentitytest tests our viridentity module which is
compiled on all platforms and OSes. There is no need to have
SELinux secdriver as individual test cases are skipped if SELinux
is missing.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Successfully build here:
https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/213586713
While technically this is a v2 of:
https://www.redhat.com/archives/libvir-list/2020-November/msg00308.html
it's implementing completely different approach and thus I did not mark
it as v2.
tests/meson.build | 2 +-
tests/viridentitytest.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/tests/meson.build b/tests/meson.build
index 8decdfa20c..9f0051303d 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -312,6 +312,7 @@ tests += [
{ 'name': 'virfirewalltest' },
{ 'name': 'virhostcputest', 'link_whole': [ test_file_wrapper_lib ] },
{ 'name': 'virhostdevtest' },
+ { 'name': 'viridentitytest' },
{ 'name': 'viriscsitest' },
{ 'name': 'virkeycodetest' },
{ 'name': 'virkmodtest' },
@@ -480,7 +481,6 @@ if conf.has('WITH_SECDRIVER_SELINUX')
if conf.has('WITH_LIBATTR')
tests += [
{ 'name': 'securityselinuxtest' },
- { 'name': 'viridentitytest' },
]
if conf.has('WITH_QEMU')
diff --git a/tests/viridentitytest.c b/tests/viridentitytest.c
index fd01eeaa80..afb9fdaec4 100644
--- a/tests/viridentitytest.c
+++ b/tests/viridentitytest.c
@@ -88,8 +88,7 @@ static int testIdentityGetSystem(const void *data)
#if !WITH_SELINUX
if (context) {
VIR_DEBUG("libvirt not compiled with SELinux, skipping this test");
- ret = EXIT_AM_SKIP;
- return -1;
+ return EXIT_AM_SKIP;
}
#endif
--
2.26.2
4 years, 1 month
[PATCH 0/9] docs: kbase style change and cleanups
by Peter Krempa
Some patches are taken from an older series where we've discussed that
the kbase page should look more like 'docs.html' as more articles
appear, this series delivers that:
https://www.redhat.com/archives/libvir-list/2020-August/msg00172.html
... and a few other changes.
Final output:
https://pipo.sk.gitlab.io/-/libvirt/-/jobs/830387801/artifacts/website/do...
Peter Krempa (9):
docs: Fix title of 'docs' page
docs: xslt: Use 'Link' rather than 'Permalink' in header links
docs: css: Add a gray box around table of contents of RST based docs
docs: kbase: Move index page to docs/kbase
docs: kbase: Remove extra container from index page
docs: kbase: Split articles into sections
docs: xsl: Unify stylability of main container element
docs: css: Modify appearance of the kbase directory page
docs: kbase: Reorder some articles in the 'Usage' section
docs/docs.html.in | 5 ++--
docs/index.html.in | 4 +--
docs/kbase.rst | 53 ---------------------------------
docs/kbase/index.rst | 57 +++++++++++++++++++++++++++++++++++
docs/kbase/meson.build | 1 +
docs/libvirt.css | 67 +++++++++++++++++++++++++++---------------
docs/meson.build | 1 -
docs/page.xsl | 27 ++++++++++-------
scripts/hvsupport.py | 2 +-
9 files changed, 124 insertions(+), 93 deletions(-)
delete mode 100644 docs/kbase.rst
create mode 100644 docs/kbase/index.rst
--
2.26.2
4 years, 1 month
[PATCH 0/4] qemu: hotplug: Fix check whether controler is used
by Peter Krempa
Patch 2/4 is the actual fix, other patches are additional cleanups.
Peter Krempa (4):
qemuDomain(Disk)ControllerIsBusy: Fix function header format
qemuDomainDiskControllerIsBusy: Fix logic of matching disk bus to
controller type
qemuDomainDiskControllerIsBusy: Optimize checking for SCSI hostdevs
qemuDomainControllerIsBusy: Fully populate switch statement
src/qemu/qemu_hotplug.c | 92 ++++++++++++++++++++++++++++++-----------
1 file changed, 69 insertions(+), 23 deletions(-)
--
2.28.0
4 years, 1 month
[PATCH] qemu: backup: Install bitmap for incremental backup to appropriate node only
by Peter Krempa
Libvirt's backup code has two modes:
1) push - where qemu actively writes the difference since the checkpoint
into the output file
2) pull - where we instruct qemu to expose a frozen disk state along
with a bitmap of blocks which changed since the checkpoint
For push mode qemu needs the temporary bitmap we use where we calculate
the actual changes to be present on the block node backing the disk.
For pull mode where we expose the bitmap via NBD qemu actually wants the
bitmap to be present for the exported block node which is the scratch
file.
Until now we've calculated the bitmap twice and installed it both to the
scratch file and to the disk node, but we don't need to since we know
when it's needed.
Pass in the 'pull' flag and decide where to install the bitmap according
to it and also when to register the bitmap name with the blockjob.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_backup.c | 42 ++++++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/src/qemu/qemu_backup.c b/src/qemu/qemu_backup.c
index 99dee46c4f..09f7921ea7 100644
--- a/src/qemu/qemu_backup.c
+++ b/src/qemu/qemu_backup.c
@@ -109,6 +109,7 @@ struct qemuBackupDiskData {
virStorageSourcePtr terminator;
virStorageSourcePtr backingStore;
char *incrementalBitmap;
+ const char *domdiskIncrementalBitmap; /* name of temporary bitmap installed on disk source */
qemuBlockStorageSourceChainDataPtr crdata;
bool labelled;
bool initialized;
@@ -201,6 +202,7 @@ qemuBackupDiskPrepareOneBitmapsChain(virStorageSourcePtr backingChain,
static int
qemuBackupDiskPrepareOneBitmaps(struct qemuBackupDiskData *dd,
virJSONValuePtr actions,
+ bool pull,
GHashTable *blockNamedNodeData)
{
if (!qemuBlockBitmapChainIsValid(dd->domdisk->src,
@@ -212,21 +214,29 @@ qemuBackupDiskPrepareOneBitmaps(struct qemuBackupDiskData *dd,
return -1;
}
- if (qemuBackupDiskPrepareOneBitmapsChain(dd->domdisk->src,
- dd->domdisk->src,
- dd->incrementalBitmap,
- dd->backupdisk->incremental,
- actions,
- blockNamedNodeData) < 0)
- return -1;
+ /* For pull-mode backup, we need the bitmap to be present in the scratch
+ * file as that will be exported. For push-mode backup the bitmap is
+ * actually required on top of the image backing the disk */
- if (qemuBackupDiskPrepareOneBitmapsChain(dd->domdisk->src,
- dd->store,
- dd->incrementalBitmap,
- dd->backupdisk->incremental,
- actions,
- blockNamedNodeData) < 0)
- return -1;
+ if (pull) {
+ if (qemuBackupDiskPrepareOneBitmapsChain(dd->domdisk->src,
+ dd->store,
+ dd->incrementalBitmap,
+ dd->backupdisk->incremental,
+ actions,
+ blockNamedNodeData) < 0)
+ return -1;
+ } else {
+ if (qemuBackupDiskPrepareOneBitmapsChain(dd->domdisk->src,
+ dd->domdisk->src,
+ dd->incrementalBitmap,
+ dd->backupdisk->incremental,
+ actions,
+ blockNamedNodeData) < 0)
+ return -1;
+
+ dd->domdiskIncrementalBitmap = dd->backupdisk->incremental;
+ }
return 0;
}
@@ -293,12 +303,12 @@ qemuBackupDiskPrepareDataOne(virDomainObjPtr vm,
else
dd->incrementalBitmap = g_strdup_printf("backup-%s", dd->domdisk->dst);
- if (qemuBackupDiskPrepareOneBitmaps(dd, actions, blockNamedNodeData) < 0)
+ if (qemuBackupDiskPrepareOneBitmaps(dd, actions, pull, blockNamedNodeData) < 0)
return -1;
}
if (!(dd->blockjob = qemuBlockJobDiskNewBackup(vm, dd->domdisk, dd->store,
- dd->incrementalBitmap)))
+ dd->domdiskIncrementalBitmap)))
return -1;
/* use original disk as backing to prevent opening the backing chain */
--
2.28.0
4 years, 1 month
