[libvirt PATCH] qemu: drop support for monitor connections on PTYs
by Daniel P. Berrangé
Libvirt switched to using a UNIX socket for monitors in
2009 for version 0.7.0. It seems unlikely that there is
a running QEMU process that hasn't been restarted for
11 years while also taking a libvirt upgrade. Therefore
we can drop support for opening a PTY for the QEMU
monitor.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/qemu/qemu_monitor.c | 43 ++++++++---------------------------------
1 file changed, 8 insertions(+), 35 deletions(-)
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 802ad20aa1..e998586a6b 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -77,7 +77,6 @@ struct _qemuMonitor {
* = 0: not registered
* < 0: an error occurred during the registration of @fd */
int watch;
- int hasSendFD;
virDomainObjPtr vm;
@@ -434,12 +433,6 @@ qemuMonitorIOWrite(qemuMonitorPtr mon)
if (!mon->msg || mon->msg->txOffset == mon->msg->txLength)
return 0;
- if (mon->msg->txFD != -1 && !mon->hasSendFD) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("Monitor does not support sending of file descriptors"));
- return -1;
- }
-
buf = mon->msg->txBuffer + mon->msg->txOffset;
len = mon->msg->txLength - mon->msg->txOffset;
if (mon->msg->txFD == -1)
@@ -707,7 +700,6 @@ qemuMonitorIO(int watch, int fd, int events, void *opaque)
static qemuMonitorPtr
qemuMonitorOpenInternal(virDomainObjPtr vm,
int fd,
- bool hasSendFD,
qemuMonitorCallbacksPtr cb,
void *opaque)
{
@@ -736,7 +728,6 @@ qemuMonitorOpenInternal(virDomainObjPtr vm,
goto cleanup;
}
mon->fd = fd;
- mon->hasSendFD = hasSendFD;
mon->vm = virObjectRef(vm);
mon->waitGreeting = true;
mon->cb = cb;
@@ -810,7 +801,6 @@ qemuMonitorOpen(virDomainObjPtr vm,
void *opaque)
{
int fd = -1;
- bool hasSendFD = false;
qemuMonitorPtr ret = NULL;
timeout += QEMU_DEFAULT_MONITOR_WAIT;
@@ -819,28 +809,18 @@ qemuMonitorOpen(virDomainObjPtr vm,
* deleted until the monitor gets its own reference. */
virObjectRef(vm);
- switch (config->type) {
- case VIR_DOMAIN_CHR_TYPE_UNIX:
- hasSendFD = true;
- virObjectUnlock(vm);
- fd = qemuMonitorOpenUnix(config->data.nix.path,
- vm->pid, retry, timeout);
- virObjectLock(vm);
- break;
-
- case VIR_DOMAIN_CHR_TYPE_PTY:
- virObjectUnlock(vm);
- fd = qemuMonitorOpenPty(config->data.file.path);
- virObjectLock(vm);
- break;
-
- default:
+ if (config->type != VIR_DOMAIN_CHR_TYPE_UNIX) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("unable to handle monitor type: %s"),
virDomainChrTypeToString(config->type));
- break;
+ goto cleanup;
}
+ virObjectUnlock(vm);
+ fd = qemuMonitorOpenUnix(config->data.nix.path,
+ vm->pid, retry, timeout);
+ virObjectLock(vm);
+
if (fd < 0)
goto cleanup;
@@ -850,7 +830,7 @@ qemuMonitorOpen(virDomainObjPtr vm,
goto cleanup;
}
- ret = qemuMonitorOpenInternal(vm, fd, hasSendFD, cb, opaque);
+ ret = qemuMonitorOpenInternal(vm, fd, cb, opaque);
cleanup:
if (!ret)
VIR_FORCE_CLOSE(fd);
@@ -2675,13 +2655,6 @@ qemuMonitorSendFileHandle(qemuMonitorPtr mon,
return -1;
}
- if (!mon->hasSendFD) {
- virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
- _("qemu is not using a unix socket monitor, "
- "cannot send fd %s"), fdname);
- return -1;
- }
-
return qemuMonitorJSONSendFileHandle(mon, fdname, fd);
}
--
2.24.1
4 years, 10 months
[libvirt PATCH 0/5] qemu: add stricter checks of permissibility of the QoS parameter 'floor'
by Pavel Mores
Aims to fix
https://bugzilla.redhat.com/show_bug.cgi?id=1750219
Libvirt previously silently accepted attempts to set 'floor' even for
direct bridge interface types where the parameter is not supported. This
could happen when manipulating both inactive and active (e.g. via 'virsh
domiftune') domain configuration.
Pavel Mores (5):
qemu: fail on attempt to set 'floor' if interface type is not
'network'
qemu: check if 'floor' is supported for given interface and network
qemu: call networkPlugBandwidth() for all types of network
docs: QoS parameter 'floor' is supported for 'open' networks too
qemu: reuse convenience variable introduced in a00b97f27672b3
docs/formatnetwork.html.in | 2 +-
src/network/bridge_driver.c | 27 +++++++++++++++++++++------
src/qemu/qemu_driver.c | 13 ++++++++++---
3 files changed, 32 insertions(+), 10 deletions(-)
--
2.24.1
4 years, 10 months
[libvirt] [patch v2 1/1] virt-aa-helper: Add support for smartcard host-certificates
by Arnaud Patard
When emulating smartcard with host certificates, qemu needs to
be able to read the certificates files. Add necessary code to
add the smartcard certificates file path to the apparmor profile.
Passthrough support has been tested with spicevmc and remote-viewer.
v2:
- Fix CodingStyle
- Add support for 'host' case.
- Add a comment to mention that the passthrough case doesn't need
some configuration
- Use one rule with '{,*}' instead of two rules.
Signed-off-by: Arnaud Patard <apatard(a)hupstream.com>
Index: libvirt/src/security/virt-aa-helper.c
===================================================================
--- libvirt.orig/src/security/virt-aa-helper.c
+++ libvirt/src/security/virt-aa-helper.c
@@ -1271,6 +1271,39 @@ get_files(vahControl * ctl)
}
}
+ for (i = 0; i < ctl->def->nsmartcards; i++) {
+ virDomainSmartcardDefPtr sc = ctl->def->smartcards[i];
+ virDomainSmartcardType sc_type = sc->type;
+ char *sc_db = (char *)VIR_DOMAIN_SMARTCARD_DEFAULT_DATABASE;
+ if (sc->data.cert.database)
+ sc_db = sc->data.cert.database;
+ switch (sc_type) {
+ /*
+ * Note: At time of writing, to get this working, qemu seccomp sandbox has
+ * to be disabled or the host must be running QEMU with commit
+ * 9a1565a03b79d80b236bc7cc2dbce52a2ef3a1b8.
+ * It's possibly due to libcacard:vcard_emul_new_event_thread(), which calls
+ * PR_CreateThread(), which calls {g,s}etpriority(). And resourcecontrol seccomp
+ * filter forbids it (cf src/qemu/qemu_command.c which seems to always use
+ * resourcecontrol=deny).
+ */
+ case VIR_DOMAIN_SMARTCARD_TYPE_HOST:
+ virBufferAddLit(&buf, " \"/etc/pki/nssdb/{,*}\" rk,\n");
+ break;
+ case VIR_DOMAIN_SMARTCARD_TYPE_HOST_CERTIFICATES:
+ virBufferAsprintf(&buf, " \"%s/{,*}\" rk,\n", sc_db);
+ break;
+ /*
+ * Nothing to do for passthrough, as the smartcard
+ * access is done through TCP or Spice
+ */
+ case VIR_DOMAIN_SMARTCARD_TYPE_PASSTHROUGH:
+ break;
+ case VIR_DOMAIN_SMARTCARD_TYPE_LAST:
+ break;
+ }
+ }
+
if (ctl->def->virtType == VIR_DOMAIN_VIRT_KVM) {
for (i = 0; i < ctl->def->nnets; i++) {
virDomainNetDefPtr net = ctl->def->nets[i];
4 years, 10 months
[PATCH v1 00/14] vircgroup code duplication purge
by Daniel Henrique Barboza
Hi,
This is my attempt to a side quest from Cole Robinson reported
in the wiki. It started with an innocent code duplication
reduction work, then I got dragged into code duplication
inside LXC and QEMU drivers. There is a significant amount of
code sharing between LXC and QEMU drivers that should be handled
in a work on its own, but I didn't shy away from the duplications
that are related to vircgroup code in some capacity.
Last 3 patches are an attempt to clean up libvirt_private.syms a
bit, turning some vircgroup functions to static after the changes
made. These are trivial, but annoying changes to review in a single
patch - hence 3 patches to allow for happier reviews. The maintainer is
free to merge the those together when pushing.
Daniel Henrique Barboza (14):
vircgroup: add virCgroupSetupBlkioTune()
vircgroup: add virCgroupSetupMemtune()
vircgroup: add virCgroupSetupCpusetCpus()
vircgroup: add virCgroupSetAndRetrieveCpuShares()
vircgroup: add virCgroupSetupCpuPeriodQuota()
domain_conf: add virDomainMergeBlkioDevice()
domain_conf: add virDomainParseBlkioDeviceStr()
vircgroup: add virCgroupSetupDomainBlkioParameters()
domain_conf: add virDomainParseMergePersistentDefBlkioParams()
vircgroup: add virCgroupSetMemoryLimitParameters()
vircgroup: add virCgroupGetCpuPeriodQuota()
vircgroup: turn virCgroup{Get/Set}BlkioDevice* static
vircgroup: turn SetMemory and SetCpusetCpus functions static
vircgroup: turn more cgroup functions static
src/conf/domain_conf.c | 222 ++++++++++++++++++++
src/conf/domain_conf.h | 13 ++
src/libvirt_private.syms | 31 +--
src/lxc/lxc_cgroup.c | 91 +-------
src/lxc/lxc_driver.c | 428 ++------------------------------------
src/qemu/qemu_cgroup.c | 113 +---------
src/qemu/qemu_driver.c | 399 +----------------------------------
src/util/vircgroup.c | 436 +++++++++++++++++++++++++++++++++++----
src/util/vircgroup.h | 75 +++----
9 files changed, 707 insertions(+), 1101 deletions(-)
--
2.24.1
4 years, 10 months
[libvirt PATCH] docs: Improve documentation for <serial> and <console>
by Andrea Bolognani
Users expect to be able to configure the <console> element and see
that configuration reflected into the <serial> element or at least
sticking, however due to our crazy back-compat code that doesn't
always happen.
There's really not much we can do to make this kind of corner cases
work as the user would expect, especially not without introducing
additional complexity in a part of libvirt that already has more
than a fair share of it; we can, however, improve the documentation
so that it will nudge said users in the right direction.
https://bugzilla.redhat.com/show_bug.cgi?id=1770725
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/formatdomain.html.in | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 44e2062d01..5ccf39abd1 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -7510,7 +7510,10 @@ qemu-kvm -net nic,model=? /dev/null
<span class="since">since 4.7.0</span>, <code>16550a</code> (usable
with the <code>system-serial</code> target type);
<code>sclpconsole</code> and <code>sclplmconsole</code> (usable with
- the <code>sclp-serial</code> target type).
+ the <code>sclp-serial</code> target type). Providing a target model is
+ usually unnecessary: libvirt will automatically pick one that's suitable
+ for the chosen target type, and overriding that value is generally not
+ recommended.
</p>
<p>
@@ -7656,7 +7659,8 @@ qemu-kvm -net nic,model=? /dev/null
for early boot logging / interactive / recovery use, and one
paravirtualized serial console to be used eg. as a side channel. Most
people will be fine with having just the first <code>console</code>
- element in their configuration.
+ element in their configuration, but if a specific configuration is
+ desired then both elements should be specified.
</p>
<p>
--
2.24.1
4 years, 10 months
[PATCH 0/6] update tls files without restarting libvirtd
by Zhang Bo
When a client wants to establish a TLS connection with libvirtd, a CRL
file， CA cert and server cert/key are used. Right
now, if these files are changed, you must restart libvirtd to make them
take effect. The restart behavior of libvirtd will cause clients
connecting with libvirtd to fail.
In a server cluster, these files, mostly the CRL, may be updated
quite frequently dueto the large amount of certificates. If the new
file does not take effect in time, there are security risks. So you
may need to restart libvirtd frequently to make the CRL etc. take
effect in time. However, frequent restarts will affect the reliability
of cluster virtual machine management(such as openstack) services.
These patches add a virt-admin command to update the tls related files
*online*.
Zhang Bo (6):
virnettlscontext: refactoring virNetTLSContextLoadCredentials
virnetserver: Introduce virNetServerUpdateTlsFiles
admin: Introduce virAdmServerUpdateTlsFiles
admin: support server cert update mode
virt-admin: Introduce command srv-update-tls
docs: update virt-admin.rst for server-update-tls
docs/manpages/virt-admin.rst | 21 ++++
include/libvirt/libvirt-admin.h | 26 ++++
src/admin/admin_protocol.x | 13 +-
src/admin/admin_server.c | 8 ++
src/admin/admin_server.h | 4 +
src/admin/libvirt-admin.c | 39 ++++++
src/admin/libvirt_admin_private.syms | 1 +
src/admin/libvirt_admin_public.syms | 1 +
src/libvirt_remote.syms | 1 +
src/rpc/virnetserver.c | 81 ++++++++++++
src/rpc/virnetserver.h | 4 +
src/rpc/virnetserverclient.c | 4 +
src/rpc/virnettlscontext.c | 179 +++++++++++++++++++--------
src/rpc/virnettlscontext.h | 3 +
tools/virt-admin.c | 88 +++++++++++++
15 files changed, 419 insertions(+), 54 deletions(-)
--
2.23.0.windows.1
4 years, 10 months
[libvirt PATCH 0/7] virshtest: remove virTestCaptureProgramOutput
by Ján Tomko
Use virCommand instead of open-coding it and do some other cleanups
found along the way.
Ján Tomko (7):
testutils: check return value of g_setenv
testutils: use g_autofree
testutils: use g_autoptr
testutils: remove unnecessary labels
virshtest: refactor testCompareOutputLit
virshtest: use virCommand instead of custom impl
testutils: remove now unused virTestCaptureProgramOutput
tests/testutils.c | 171 +++++++++-------------------------------------
tests/testutils.h | 2 -
tests/virshtest.c | 35 ++++++----
3 files changed, 54 insertions(+), 154 deletions(-)
--
2.21.1
4 years, 10 months
[libvirt PATCH 0/9] syntax-check: fix sc-prohibit-cross-inclusion
by Ján Tomko
And drop some legacy stuff, since I already had to open the file.
Ján Tomko (9):
syntax-check: do not enforce ChangeLog syntax
syntax-check: fix sc-prohibit-cross-inclusion
syntax-check: drop vulnerable Makefile checks
syntax-check: drop CVS keyword expansion check
syntax-check: drop update-NEWS-hash
syntax-check: exclude: remove deleted files
syntax-check: exclude: remove virstring
syntax-check: remove README
syntax-check: remove some exception mechanisms
build-aux/syntax-check.mk | 73 +++------------------------------------
1 file changed, 5 insertions(+), 68 deletions(-)
--
2.24.1
4 years, 10 months
glib crash via eventtest.c
by Cole Robinson
I attempted to review some patches on Friday and started hitting
occasional crashes via eventtest.c. Long story short it's a glib bug:
https://gitlab.gnome.org/GNOME/glib/merge_requests/1358
It's a ref counting issue caused when g_source_remove
(virEventRemoveHandle) is called from one thread, while the main loop is
in a particular state in a different thread.
The way vireventglib is implemented means every user initiated
g_source_remove is likely called from a different thread so we risk
hitting this. Not sure how likely it is in realworld usage,
vireventtest.c is pretty pathologic in this area. We could change
vireventglib.c to do the final source_unref from the idle callback which
would avoid the problem
Thanks,
Cole
4 years, 10 months
Fwd: FW: [libvirt PATCH 0/6] Introduce Local Migration Support in Libvirt
by Prerna
On 2/3/20, 7:16 PM, "Daniel P. Berrangé" <berrange(a)redhat.com> wrote:
On Mon, Feb 03, 2020 at 10:42:48AM -0300, Daniel Henrique Barboza
wrote:
> Hi Daniel,
>
> I am happy that Libvirt is pushing local migration/live patching
support, but
> at the same time I am wondering what changed from what you said
here:
Err, this isn't libvirt pushing local migration. I'm simply
re-posting
these patches on behalf of Shaju who is unable to post the patches
due
to our broken mail server. Don't take this as meaning that I
approve of
the patches. They're simply here for discussion as any other patch
proposal is.
Thank you for forwarding the patch to the list, Danpb.
That is largely still my view.
Sure, and we will be happy to discuss this further, as noted below :)
> To give you a background, we have live patching enhancements in
IBM backlog
> since a few years ago, and one on the reasons these were being
postponed
> time and time again were the lack of Libvirt support and this
direction of
> "Libvirt is not interested in supporting it". And this message
above was being
> used internally as the rationale for it.
Hi Daniel HB,
Thank you for pointing out the fact that this has been in discussion
since 2013. While Shaju's patches were independent as an RFC, we will be
happy to collaborate to push for a joint solution. The fact that this has
been requested time and again, and the fact that most commercial cloud
deployments out there already have an in-place upgrade story [1] [2] --
should be good reason we holistically examine the use case once again.
[1] https://kb.vmware.com/s/article/2005389
[2] https://dl.acm.org/doi/10.1145/3297858.3304034
Danpb had explained in much detail as to why mangling file and particularly
socket paths can be messy in this patchset. However, even if libvirtd
blocks in-place migrations for such legacy VMs until apps switch to more
stringent XML semantics, it still may help cutting edge apps that intend to
leverage this.
I understand the presence of collision-causing file and socket paths can
easily be checked as pre-migration checks, and should be trivial to
implement.
We can include a revised patchset with this check in place. Support for
this feature has been present in qemu for a while for this use-case, and so
maybe it is time we pass on the goodness up the stack as well.
Happy to discuss more details on implementation and semantics,
Warm regards,
Prerna Saxena
4 years, 10 months
