[libvirt] Can jobs suck like qemu-pr-helper does be transfered to libvirtd?
by Zhangbo (Oscar)
Hi all:
qemu-pr-helper exits to help qemu do the high-privileged scsi related jobs. LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set selinux/DAC labels for them and their socket.
#
#
#
#
# ___________
# ___________|libvirtd |__________
# | |___________| |
# | | |
# | | |
# _________|________ _____|______ ___|____
# | qemu-pr-helper |__| vm1.sock |_____| qemu1 |
# |__________________| |____________| |________|
There may be other jobs quite like qemu-pr-helper, shall we make them as "complex" as the qemu-pr-helper scheme?
Will it be OK to just let qemu send an EVENT to libvirtd, and let libvirtd do the SCSI/other jobs? Will it be OK if we remove qemu-pr-helper and similar processes?
What's the disadvantage if we let libvirtd do there high privileged jobs instead qemu-pr-helper-like processes?
Thanks!
5 years, 1 month
[libvirt] vcpupin reports bogus vcpu affinities
by Allen, John
Sent this out to the list a few days ago, but never saw it appear on the
archives. Resending--hopefully this makes it to the list.
---
For pinned vcpus, vcpupin will report inaccurate affinity values on machines
with high core counts (256 cores in my case). The problem is produced as
follows:
$ virsh vcpupin myguest 0 4
$ virsh vcpupin myguest 0
VCPU CPU Affinity
---------------------------
0 4,192,194,196-197
Running taskset on the qemu threads shows the correct affinity, so this seems
to be a reporting problem. Strangely, the value "192" is significant. If I pin
a cpu greater than 192, the problem no longer appears.
I believe the cause of the problem in my case is that in this case in
src/conf/domain_conf.c:virDomainDefGetVcpuPinInfoHelper:
...
if (vcpu && vcpu->cpumask)
bitmap = vcpu->cpumask;
...
vcpu->cpumask is "shortened" in that it is only long enough to contain the last
set bit in the mask. However, when we go to copy the mask to the buffer that is
returned, we use the masklen passed to the function which is the "full"
masklen with a bit for each cpu. So it seems virBitmapToDataBuf copies some
extra data past the end of the bitmask. Why the "192" value is always set and I
typically see similar bogus bits set is still unknown.
What is the function meant to assume in this case? Is it sane to assume that
the bitmask is the full length of the buffer here and it's the responsibility
of the setter of vcpu->cpumask to provide the length of the bitmap we're
expecting? Or should we assume that we may receive a shortened bitmask here and
expand the bitmask before copying to the buffer?
-John
5 years, 1 month
[libvirt] [PATCH v2 0/7] extend virsh domstate to show additional information
by Bjoern Walk
This patch series introduces the ability to save additional information
for the domain state and exposes this information in virsh domstate.
For example in the case of QEMU guest panic events, we can provide additional
information like the crash reason or register state of the domain. This
information usually gets logged in the domain log but for debugging it is
useful to have it accessible from the client. Therefore, let's introduce a new
public API function, virDomainGetStateParams, an extensible version of
virDomainGetState, which returns the complete state of the domain, including
newly introduced additional information.
Let's also extend virsh domstate and introduce a new parameter --info to show
the domain state, reason and additional information when available.
virsh domstate --info guest1
crashed (panicked: s390: core='1' psw-mask='0x1234000000000000' \
psw-addr='0x0000000000001234' reason='disabled-wait')
Previous version is here:
https://www.redhat.com/archives/libvir-list/2018-July/msg00686.html
v1 -> v2:
* refactored the public API according to discussions to provide a
more machine-parsable interface
Bjoern Walk (7):
qemu: monitor: move event data structure to domain
qemu: domain: store and update panic info
lib: introduce virDomainGetStateParams function
remote: implement remoteDomainGetStateParams
qemu: implement qemuDomainGetStateParams
virsh: domstate: report detailed state if available
news: add entry for virDomainGetStateParams
docs/news.xml | 11 +++
include/libvirt/libvirt-domain.h | 76 +++++++++++++++++
src/driver-hypervisor.h | 9 ++
src/libvirt-domain.c | 64 ++++++++++++++
src/libvirt_public.syms | 1 +
src/qemu/qemu_domain.c | 89 +++++++++++++++++++-
src/qemu/qemu_domain.h | 47 +++++++++++
src/qemu/qemu_driver.c | 126 +++++++++++++++++++++++++++-
src/qemu/qemu_monitor.c | 53 +-----------
src/qemu/qemu_monitor.h | 48 ++---------
src/qemu/qemu_monitor_json.c | 20 ++---
src/qemu/qemu_process.c | 2 +-
src/remote/remote_daemon_dispatch.c | 50 +++++++++++
src/remote/remote_driver.c | 44 ++++++++++
src/remote/remote_protocol.x | 22 ++++-
src/remote_protocol-structs | 12 +++
tools/virsh-domain-monitor.c | 102 +++++++++++++++++++---
tools/virsh.pod | 5 +-
18 files changed, 658 insertions(+), 123 deletions(-)
--
2.17.0
5 years, 1 month
[libvirt] [PATCH] apparmor: support QEMU hppa, nios2, or1k, riscv32 and riscv64
by intrigeri+libvirt＠boum.org
From: intrigeri <intrigeri+libvirt(a)boum.org>
Fixes: https://bugs.debian.org/914940
---
src/security/apparmor/libvirt-qemu | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/security/apparmor/libvirt-qemu b/src/security/apparmor/libvirt-qemu
index 474aaefdf8..165558fe83 100644
--- a/src/security/apparmor/libvirt-qemu
+++ b/src/security/apparmor/libvirt-qemu
@@ -103,6 +103,7 @@
/usr/bin/qemu-system-alpha rmix,
/usr/bin/qemu-system-arm rmix,
/usr/bin/qemu-system-cris rmix,
+ /usr/bin/qemu-system-hppa rmix,
/usr/bin/qemu-system-i386 rmix,
/usr/bin/qemu-system-lm32 rmix,
/usr/bin/qemu-system-m68k rmix,
@@ -113,10 +114,14 @@
/usr/bin/qemu-system-mips64el rmix,
/usr/bin/qemu-system-mipsel rmix,
/usr/bin/qemu-system-moxie rmix,
+ /usr/bin/qemu-system-nios2 rmix,
+ /usr/bin/qemu-system-or1k rmix,
/usr/bin/qemu-system-or32 rmix,
/usr/bin/qemu-system-ppc rmix,
/usr/bin/qemu-system-ppc64 rmix,
/usr/bin/qemu-system-ppcemb rmix,
+ /usr/bin/qemu-system-riscv32 rmix,
+ /usr/bin/qemu-system-riscv64 rmix,
/usr/bin/qemu-system-s390x rmix,
/usr/bin/qemu-system-sh4 rmix,
/usr/bin/qemu-system-sh4eb rmix,
--
2.20.1
5 years, 1 month
[libvirt] [PATCH v2 0/4] apps: update the listed libvirt apps
by Daniel P. Berrangé
Purge apps that are dead and fix broken links
Daniel P. Berrangé (4):
apps: remove dead archipel project
apps: update link for buildbot
apps: drop link for zenoss software
apps: remove VM Manager android app
docs/apps.html.in | 39 +--------------------------------------
1 file changed, 1 insertion(+), 38 deletions(-)
--
2.20.1
5 years, 1 month
[libvirt] [PATCH] news: Update for 5.2.0 release
by Andrea Bolognani
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/news.xml | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 2067830848..fcf8520132 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -148,8 +148,45 @@
tables are not required.
</description>
</change>
+ <change>
+ <summary>
+ Don't default to building the QEMU driver
+ </summary>
+ <description>
+ Historically, the QEMU driver has been special in that it was
+ enabled by default, with the option to explicitly opt-out of it;
+ starting now, we're enabling it opportunistically if we detect that
+ all requirements are available, just like we do with other drivers.
+ </description>
+ </change>
</section>
<section title="Bug fixes">
+ <change>
+ <summary>
+ virt-host-validate: Fix IOMMU check on s390x
+ </summary>
+ </change>
+ <change>
+ <summary>
+ qemu: Allow creating pSeries guests with graphics and no USB mouse
+ </summary>
+ <description>
+ It's now possible to prevent libvirt from automatically adding a
+ USB mouse to pSeries guests by including a USB tablet in the input
+ XML: doing so is desiderable as using a tablet results in a much
+ better user experience when working with GUIs.
+ </description>
+ </change>
+ <change>
+ <summary>
+ qemu: Set $HOME and XGD variables for qemu:///system guests
+ </summary>
+ <description>
+ This avoids files being accidentally created under <code>/</code> or
+ the guests not being able to start because they lack the necessary
+ permissions to write to that location.
+ </description>
+ </change>
</section>
</release>
<release version="v5.1.0" date="2019-03-04">
--
2.20.1
5 years, 1 month
[libvirt] [PATCH 0/4] apps: update the listed libvirt apps
by Daniel P. Berrangé
Purge apps that are dead and fix broken links
Daniel P. Berrangé (4):
apps: remove dead archipel project
apps: update link for buildbot
apps: update link for zenoss software
apps: remove VM Manager android app
docs/apps.html.in | 35 ++---------------------------------
1 file changed, 2 insertions(+), 33 deletions(-)
--
2.20.1
5 years, 1 month
[libvirt] [PATCH 0/6] qemu: caps: Clean up virQEMUCapsInitQMPMonitor
by Peter Krempa
Some cleanups done while attempting to implement a new capability.
Peter Krempa (6):
qemu: caps: Separate capabilities based on qemu version
qemu: caps: Aggregate all caps post-processing into a function
qemu: capabilities: Move logic deciding whether to probe into probing
functions
qemu: caps: Don't leak package name string in
virQEMUCapsInitQMPMonitor
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor
qemu: caps: Remove pointless debug message in
virQEMUCapsInitQMPMonitor
src/qemu/qemu_capabilities.c | 278 +++++++++++++++++++----------------
1 file changed, 150 insertions(+), 128 deletions(-)
--
2.20.1
5 years, 1 month
[libvirt] [PATCH v2 1/2] qemu: Fix "boolen" typo in API doc
by Christophe Fergeau
This also adjusts the argument name which should be 'isListen' in both
cases rather than 'listen'.
Signed-off-by: Christophe Fergeau <cfergeau(a)redhat.com>
---
Changes since v1:
- really fix 'boolen' typo
src/qemu/qemu_command.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f81d20e5f7..82675c5d4e 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -876,7 +876,7 @@ qemuBuildRBDSecinfoURI(virBufferPtr buf,
/* qemuBuildTLSx509BackendProps:
* @tlspath: path to the TLS credentials
- * @listen: boolen listen for client or server setting
+ * @isListen: boolean listen for client or server setting
* @verifypeer: boolean to enable peer verification (form of authorization)
* @alias: alias for the TLS credentials object
* @secalias: if one exists, the alias of the security object for passwordid
@@ -917,7 +917,7 @@ qemuBuildTLSx509BackendProps(const char *tlspath,
/* qemuBuildTLSx509CommandLine:
* @cmd: Pointer to command
* @tlspath: path to the TLS credentials
- * @listen: boolen listen for client or server setting
+ * @isListen: boolean listen for client or server setting
* @verifypeer: boolean to enable peer verification (form of authorization)
* @certEncSecretAlias: alias of a 'secret' object for decrypting TLS private key
* (optional)
--
2.21.0
5 years, 1 month
