[libvirt PATCH] qemu: remove some unnecessary local variables
by Jonathon Jongsma
These variables seem to be left over from a previous refactoring and
they don't add anything to the code.
Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com>
---
src/qemu/qemu_hotplug.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 2c184b9ba0..79fc8baa5c 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -5502,7 +5502,6 @@ qemuDomainDetachPrepRedirdev(virDomainObjPtr vm,
virDomainRedirdevDefPtr match,
virDomainRedirdevDefPtr *detach)
{
- virDomainRedirdevDefPtr redirdev;
ssize_t idx;
if ((idx = virDomainRedirdevDefFind(vm->def, match)) < 0) {
@@ -5511,7 +5510,7 @@ qemuDomainDetachPrepRedirdev(virDomainObjPtr vm,
return -1;
}
- *detach = redirdev = vm->def->redirdevs[idx];
+ *detach = vm->def->redirdevs[idx];
return 0;
}
@@ -5523,12 +5522,11 @@ qemuDomainDetachPrepNet(virDomainObjPtr vm,
virDomainNetDefPtr *detach)
{
int detachidx;
- virDomainNetDefPtr net = NULL;
if ((detachidx = virDomainNetFindIdx(vm->def, match)) < 0)
return -1;
- *detach = net = vm->def->nets[detachidx];
+ *detach = vm->def->nets[detachidx];
return 0;
}
@@ -5598,7 +5596,6 @@ qemuDomainDetachPrepRNG(virDomainObjPtr vm,
virDomainRNGDefPtr *detach)
{
ssize_t idx;
- virDomainRNGDefPtr rng;
if ((idx = virDomainRNGFind(vm->def, match)) < 0) {
virReportError(VIR_ERR_DEVICE_MISSING,
@@ -5608,7 +5605,7 @@ qemuDomainDetachPrepRNG(virDomainObjPtr vm,
return -1;
}
- *detach = rng = vm->def->rngs[idx];
+ *detach = vm->def->rngs[idx];
return 0;
}
@@ -5619,7 +5616,6 @@ qemuDomainDetachPrepMemory(virDomainObjPtr vm,
virDomainMemoryDefPtr match,
virDomainMemoryDefPtr *detach)
{
- virDomainMemoryDefPtr mem;
int idx;
if (qemuDomainMemoryDeviceAlignSize(vm->def, match) < 0)
@@ -5633,7 +5629,7 @@ qemuDomainDetachPrepMemory(virDomainObjPtr vm,
return -1;
}
- *detach = mem = vm->def->mems[idx];
+ *detach = vm->def->mems[idx];
return 0;
}
--
2.26.2
4 years, 1 month
[PATCH 0/2] virtiofs can be used without NUMA
by Marc Hartmayer
Halil Pasic (1):
Reflect in virtiofs.rst that virtiofs can be used without NUMA
Marc Hartmayer (1):
qemu: virtiofs can be used without NUMA nodes
docs/kbase/virtiofs.rst | 17 ++++++++++++-----
src/qemu/qemu_validate.c | 13 +++++++++----
2 files changed, 21 insertions(+), 9 deletions(-)
--
2.25.4
4 years, 1 month
[PATCH 0/2] qemu: Set noqueue qdisc for TAP devices
by Michal Privoznik
See 2/2 for detailed explanation.
Long story short - we can squeeze more bandwidth from TAP devices we
create for domains.
Michal Prívozník (2):
virnetdev: Introduce virNetDevSetRootQDisc()
qemu: Set noqueue qdisc for TAP devices
src/libvirt_private.syms | 1 +
src/qemu/qemu_command.c | 2 ++
src/qemu/qemu_domain.c | 36 +++++++++++++++++++++++++++++++
src/qemu/qemu_domain.h | 4 ++++
src/qemu/qemu_hotplug.c | 2 ++
src/util/virnetdev.c | 46 ++++++++++++++++++++++++++++++++++++++++
src/util/virnetdev.h | 3 +++
7 files changed, 94 insertions(+)
--
2.26.2
4 years, 1 month
[PATCH] qemu_slirp: Check if helper exists before fetching its capabilities
by Michal Privoznik
I've noticed when running libvirtd in the session mode that
whenever I start a virtual machine the following error is printed
into logs:
error : cannot execute binary /usr/bin/slirp-helper: No such file or directory
The error message is produced in qemuSlirpNewForHelper() which
does attempt to be a NO-OP if the helper doesn't exist by
checking if its path is NULL, but that's not usually the case
because in the default config (in virQEMUDriverConfigNew()) its
path is initialized to QEMU_SLIRP_HELPER. And while it is true
that during configure we try to get the actual path of the helper
we fallback to the path above if not found.
Fix the check so that the function checks whether the helper
exists and is executable.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_slirp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_slirp.c b/src/qemu/qemu_slirp.c
index d2e4ed79be..4e5ab12727 100644
--- a/src/qemu/qemu_slirp.c
+++ b/src/qemu/qemu_slirp.c
@@ -101,7 +101,8 @@ qemuSlirpNewForHelper(const char *helper)
virJSONValuePtr featuresJSON;
size_t i, nfeatures;
- if (!helper)
+ if (!helper ||
+ !virFileIsExecutable(helper))
return NULL;
slirp = qemuSlirpNew();
--
2.26.2
4 years, 1 month
[libvirt PATCH 0/4] vmx: start parsing SATA disks
by Pino Toscano
Try to parse SATA disks in VMware guests from their configs in VMX
files. There are a couple of helper/cleanup commits to ease a bit the
actual patches.
Pino Toscano (4):
vmx: hide private helpers
vmx: shortcut 'cdrom-image' as CD-ROM earlier
vmx: expand the disk array
vmx: start parsing SATA disks
src/libvirt_vmx.syms | 12 -
src/vmx/vmx.c | 212 ++++++++++++++++--
src/vmx/vmx.h | 44 ----
.../vmx2xml-esx-in-the-wild-10.vmx | 101 +++++++++
.../vmx2xml-esx-in-the-wild-10.xml | 36 +++
.../vmx2xmldata/vmx2xml-esx-in-the-wild-8.xml | 6 +
tests/vmx2xmltest.c | 1 +
7 files changed, 335 insertions(+), 77 deletions(-)
create mode 100644 tests/vmx2xmldata/vmx2xml-esx-in-the-wild-10.vmx
create mode 100644 tests/vmx2xmldata/vmx2xml-esx-in-the-wild-10.xml
--
2.26.2
4 years, 1 month
[RFC] qemu: virtiofs can be used without NUMA nodes
by Marc Hartmayer
...if a machine memory-backend using shared memory is configured for
the guest. This is especially important for QEMU machine types that
don't have NUMA but virtiofs support.
An example snippet:
<domain type='kvm'>
<name>test</name>
<memory unit='KiB'>2097152</memory>
<memoryBacking>
<access mode='shared'/>
</memoryBacking>
<devices>
<filesystem type='mount' accessmode='passthrough'>
<driver type='virtiofs'/>
<source dir='/tmp/test'/>
<target dir='coffee'/>
</filesystem>
...
</devices>
...
</domain>
and the corresponding QEMU command line:
/usr/bin/qemu-system-s390x \
-machine s390-ccw-virtio-5.2,memory-backend=s390.ram \
-m 2048 \
-object
memory-backend-file,id=s390.ram,mem-path=/var/lib/libvirt/qemu/ram/46-test/s390.ram,share=yes,size=2147483648 \
...
Signed-off-by: Marc Hartmayer <mhartmay(a)linux.ibm.com>
---
Note: There are still some TODOs left... e.g. adapt the virtiofs
documentation of libvirt.
---
src/qemu/qemu_validate.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index a212605579d2..077a85b30802 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -3470,14 +3470,21 @@ qemuValidateDomainDeviceDefGraphics(const virDomainGraphicsDef *graphics,
static int
-qemuValidateDomainDefVirtioFSSharedMemory(const virDomainDef *def)
+qemuValidateDomainDefVirtioFSSharedMemory(const virDomainDef *def,
+ virQEMUCapsPtr qemuCaps)
{
+ const char *defaultRAMId = virQEMUCapsGetMachineDefaultRAMid(qemuCaps,
+ def->virtType,
+ def->os.machine);
size_t numa_nodes = virDomainNumaGetNodeCount(def->numa);
size_t i;
- if (numa_nodes == 0) {
+ if (numa_nodes == 0 &&
+ !(defaultRAMId && def->mem.access == VIR_DOMAIN_MEMORY_ACCESS_SHARED)) {
+ /* TODO do we need further checks here (e.g. check whether
+ * memory backend is supported by the QEMU binary)? */
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("virtiofs requires one or more NUMA nodes"));
+ _("virtiofs requires shared memory"));
return -1;
}
@@ -3591,7 +3598,7 @@ qemuValidateDomainDeviceDefFS(virDomainFSDefPtr fs,
_("virtiofs does not support multidevs"));
return -1;
}
- if (qemuValidateDomainDefVirtioFSSharedMemory(def) < 0)
+ if (qemuValidateDomainDefVirtioFSSharedMemory(def, qemuCaps) < 0)
return -1;
break;
--
2.25.4
4 years, 1 month
[libvirt PATCH] logging: allow max_len=0 to disable log rollover
by Daniel P. Berrangé
Currently setting max_len=0 causes virtlogd to spin in a busy loop. It
is natural to allow this to disable log rollover which can be useful for
developers debugging things.
Note disabling rollover exposes the host to denial of service from a
malicious guest, so must be used with care.
Closes https://gitlab.com/libvirt/libvirt/-/issues/85
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/logging/virtlogd.conf | 4 ++++
src/util/virrotatingfile.c | 48 +++++++++++++++++++++-----------------
2 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/src/logging/virtlogd.conf b/src/logging/virtlogd.conf
index 8b1ff0156f..c53a1112bd 100644
--- a/src/logging/virtlogd.conf
+++ b/src/logging/virtlogd.conf
@@ -87,6 +87,10 @@
# Maximum file size before rolling over. Defaults to 2 MB
#
+# Setting max_size to zero will disable rollover entirely.
+# NOTE: disabling rollover exposes the host filesystem to
+# denial of service from a malicious guest.
+#
# Beware that a logrotate config file might be installed too,
# to handle cases where virtlogd is disabled. To ensure that
# the logrotate config is a no-op when virtlogd is running,
diff --git a/src/util/virrotatingfile.c b/src/util/virrotatingfile.c
index a88c332cf4..9f1ef17c3e 100644
--- a/src/util/virrotatingfile.c
+++ b/src/util/virrotatingfile.c
@@ -225,7 +225,8 @@ virRotatingFileWriterDelete(virRotatingFileWriterPtr file)
*
* The files will never exceed @maxlen bytes in size,
* but may be rolled over before they reach this size
- * in order to avoid splitting lines
+ * in order to avoid splitting lines. If @maxlen is
+ * zero then no rollover will be performed.
*/
virRotatingFileWriterPtr
virRotatingFileWriterNew(const char *path,
@@ -430,25 +431,27 @@ virRotatingFileWriterAppend(virRotatingFileWriterPtr file,
size_t towrite = len;
bool forceRollover = false;
- if (file->entry->pos > file->maxlen) {
- /* If existing file is for some reason larger then max length we
- * won't write to this file anymore, but we rollover this file.*/
- forceRollover = true;
- towrite = 0;
- } else if ((file->entry->pos + towrite) > file->maxlen) {
- towrite = file->maxlen - file->entry->pos;
-
- /*
- * If there's a newline in the last 80 chars
- * we're about to write, then break at that
- * point to avoid splitting lines across
- * separate files
- */
- for (i = 0; i < towrite && i < 80; i++) {
- if (buf[towrite - i - 1] == '\n') {
- towrite -= i;
- forceRollover = true;
- break;
+ if (file->maxlen != 0) {
+ if (file->entry->pos > file->maxlen) {
+ /* If existing file is for some reason larger then max length we
+ * won't write to this file anymore, but we rollover this file.*/
+ forceRollover = true;
+ towrite = 0;
+ } else if ((file->entry->pos + towrite) > file->maxlen) {
+ towrite = file->maxlen - file->entry->pos;
+
+ /*
+ * If there's a newline in the last 80 chars
+ * we're about to write, then break at that
+ * point to avoid splitting lines across
+ * separate files
+ */
+ for (i = 0; i < towrite && i < 80; i++) {
+ if (buf[towrite - i - 1] == '\n') {
+ towrite -= i;
+ forceRollover = true;
+ break;
+ }
}
}
}
@@ -468,8 +471,9 @@ virRotatingFileWriterAppend(virRotatingFileWriterPtr file,
file->entry->len += towrite;
}
- if ((file->entry->pos == file->maxlen && len) ||
- forceRollover) {
+ if (file->maxlen != 0 &&
+ ((file->entry->pos == file->maxlen && len) ||
+ forceRollover)) {
virRotatingFileWriterEntryPtr tmp;
VIR_DEBUG("Hit max size %zu on %s (force=%d)",
file->maxlen, file->basepath, forceRollover);
--
2.26.2
4 years, 1 month
[libvirt PATCH 0/2] fixes allocation issues leading to crashes
by Pavel Hrdina
Our libvirt-dbus tests discovered allocation issues introduced by recent
rewrite to use g_new0 instead of VIR_ALLOC_N by allocating array one
element shorter in some places which can lead to crashes of client
applications counting on a fact that the returned arrays are NULL
terminated.
Pavel Hrdina (2):
conf: fix g_new0 allocation
conf: virsecretobj: fix g_new0 allocation
src/conf/virinterfaceobj.c | 2 +-
src/conf/virnetworkobj.c | 4 ++--
src/conf/virnodedeviceobj.c | 2 +-
src/conf/virsecretobj.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
--
2.26.2
4 years, 1 month
Re: Overlay limit bug
by Peter Krempa
Adding libvir-list to cc. If you come across stuff that involves both
libvirt and qemu it's best to crosspost it to libvir-list too as I've
noticed this only accidentally.
On Mon, Oct 12, 2020 at 15:03:10 -0400, Yoonho Park wrote:
> I stumbled on a bug in qemu 4.2.0 (virsh 6.0.0) with a large number of
> overlays. I am using "qemu-img create" and "virsh snapshot-create-as" to
> create each overlay. When I run "virsh snapshot-create-as" for the 42nd
> overlay, I get "error: No complete monitor response found in 10485760
This error comes from libvirt's DoS protection. The response from qemu
is too large. This happens when 'query-named-block-nodes' is called on
too-deep backing chains as the reply contains both nested and linear
entries. Thus for a N deep backing chain, you get N + N-1 + N-2 ...
entries in the returned data.
Libvirt stops reading after 1MiB of json to prevent buffer overflows
from a rogue qemu.
> bytes: Numerical result out of range". However, I pulled down qemu 5.1.50
> (still using virsh 6.0.0), and it looks like the problem has disappeared
> which is great. Does anyone know the patch set that addressed this bug?
qemu patch:
commit facda5443f5a8676fb635b82ac1046ac6b6a67ce
Author: Peter Krempa <pkrempa(a)redhat.com>
Date: Mon Jan 20 09:50:49 2020 +0100
qapi: Allow getting flat output from 'query-named-block-nodes'
When a management application manages node names there's no reason to
recurse into backing images in the output of query-named-block-nodes.
Add a parameter to the command which will return just the top level
structs.
v4.2.0-1584-gfacda5443f
libvirt patches:
commit 95080cc8b470c977d53043d4eff3e30781f472eb
Author: Peter Krempa <pkrempa(a)redhat.com>
Date: Tue Jan 21 16:51:40 2020 +0100
qemu: Don't request nested entries in qemuBlockGetNamedNodeData
Use the 'flat' flag for 'query-named-block-nodes' if qemu supports
QEMU_CAPS_QMP_QUERY_NAMED_BLOCK_NODES_FLAT in qemuBlockGetNamedNodeData.
We don't need the data so plumb in whether qemu supports the
'flat' output.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
commit 855211bbf3ed45a73159f45eba1b15f05d771b76
Author: Peter Krempa <pkrempa(a)redhat.com>
Date: Tue Jan 21 16:42:49 2020 +0100
qemu: monitor: Add 'flat' parameter for qemuMonitorJSONQueryNamedBlockNodes
Modern qemu allows to skip the nested redundant data in the output of
query-named-block-nodes. Plumb in the support for the argument that
enables it.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
commit 63610bd5fbe67ba9eb4f22f67c4bdab6eda8c041
Author: Peter Krempa <pkrempa(a)redhat.com>
Date: Wed Feb 26 12:50:53 2020 +0100
qemuCheckpointDiscardBitmaps: Use qemuBlockGetNamedNodeData
Replace qemuMonitorBlockGetNamedNodeData by qemuBlockGetNamedNodeData.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
commit f886c9f33051fc03dd6c78134c92d31e7caf0c81
Author: Peter Krempa <pkrempa(a)redhat.com>
Date: Tue Jan 21 16:33:12 2020 +0100
qemu: monitor: Refactor variable cleanup in qemuMonitorJSONQueryNamedBlockNodes
Use g_autoptr to get rid of the cleanup section.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
commit b7991c903cdd5b3c8b79a206584a4db81a6d4eaa
Author: Peter Krempa <pkrempa(a)redhat.com>
Date: Tue Jan 21 15:13:47 2020 +0100
qemu: capabilities: Add capability for the 'flat' argument of 'query-named-block-nodes'
Detect the presence of the flag and make it available internally as
QEMU_CAPS_QMP_QUERY_NAMED_BLOCK_NODES_FLAT.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
v6.1.0-29-g95080cc8b4
> Also, does anyone know the "official" limit on the number of overlays that
> can be created and is there a qemu test that exercises this? I could not
Libvirt's official limit is 200 layers.
This is the documentation for the validation function explaining the
rationale:
/**
* qemuDomainStorageSourceValidateDepth:
* @src: storage source chain to validate
* @add: offsets the calculated number of images
* @diskdst: optional disk target to use in error message
*
* The XML parser limits the maximum element nesting to 256 layers. As libvirt
* reports the chain into the status and in some cases the config XML we must
* validate that any user-provided chains will not exceed the XML nesting limit
* when formatted to the XML.
*
* This function validates that the storage source chain starting @src is at
* most 200 layers deep. @add modifies the calculated value to offset the number
* to allow checking cases when new layers are going to be added to the chain.
*
* Returns 0 on success and -1 if the chain is too deep. Error is reported.
*/
int
qemuDomainStorageSourceValidateDepth(virStorageSourcePtr src,
int add,
const char *diskdst)
> find an overlay limit test in tests/qemu-iotests.
I'd guess qemu doesn't really limit that, but at some point you'll get
too much of a performance penalty form traversing all the structs.
4 years, 1 month
