[libvirt] [PATCH] Fix compile error for stable 1.2.9
by Yang hongyang
Seems a backport miss. An extra member is passed to struct
virLXCBasicMountInfo.
Signed-off-by: Yang hongyang <hongyang.yang(a)easystack.cn>
---
src/lxc/lxc_container.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 28dabec..1c65fa9 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -760,7 +760,7 @@ typedef struct {
static const virLXCBasicMountInfo lxcBasicMounts[] = {
{ "proc", "/proc", "proc", MS_NOSUID|MS_NOEXEC|MS_NODEV, false, false },
- { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false, false },
+ { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "sysfs", "/sys", "sysfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "securityfs", "/sys/kernel/security", "securityfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, true, true },
#if WITH_SELINUX
--
1.7.1
1 year
[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori
Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd
people that are who can throw tomatoes at me for getting bits wrong :-)
I wanted to start a discussion about supporting vhost-net in libvirt.
vhost-net has not yet been merged into qemu but I expect it will be soon
so it's a good time to start this discussion.
There are two modes worth supporting for vhost-net in libvirt. The
first mode is where vhost-net backs to a tun/tap device. This is
behaves in very much the same way that -net tap behaves in qemu today.
Basically, the difference is that the virtio backend is in the kernel
instead of in qemu so there should be some performance improvement.
Current, libvirt invokes qemu with -net tap,fd=X where X is an already
open fd to a tun/tap device. I suspect that after we merge vhost-net,
libvirt could support vhost-net in this mode by just doing -net
vhost,fd=X. I think the only real question for libvirt is whether to
provide a user visible switch to use vhost or to just always use vhost
when it's available and it makes sense. Personally, I think the later
makes sense.
The more interesting invocation of vhost-net though is one where the
vhost-net device backs directly to a physical network card. In this
mode, vhost should get considerably better performance than the current
implementation. I don't know the syntax yet, but I think it's
reasonable to assume that it will look something like -net
tap,dev=eth0. The effect will be that eth0 is dedicated to the guest.
On most modern systems, there is a small number of network devices so
this model is not all that useful except when dealing with SR-IOV
adapters. In that case, each physical device can be exposed as many
virtual devices (VFs). There are a few restrictions here though. The
biggest is that currently, you can only change the number of VFs by
reloading a kernel module so it's really a parameter that must be set at
startup time.
I think there are a few ways libvirt could support vhost-net in this
second mode. The simplest would be to introduce a new tag similar to
<source network='br0'>. In fact, if you probed the device type for the
network parameter, you could probably do something like <source
network='eth0'> and have it Just Work.
Another model would be to have libvirt see an SR-IOV adapter as a
network pool whereas it handled all of the VF management. Considering
how inflexible SR-IOV is today, I'm not sure whether this is the best model.
Has anyone put any more thought into this problem or how this should be
modeled in libvirt? Michael, could you share your current thinking for
-net syntax?
--
Regards,
Anthony Liguori
1 year
[libvirt] [PATCH v4 0/8] Virtio-crypto device support
by Longpeng(Mike)
As virtio-crypto has been supported in QEMU 2.8 and the frontend
driver has been merged in linux 4.10, so it's necessary to support
virtio-crypto in libvirt.
---
Changes since v3:
- spilt the capabilities part into a separate patch. [Boris]
- include Boris's virtio-crypto ccw support(PATCH 6 & 8). [Boris]
- add the missing capabilities in caps_2.9.0.x86_64.xml. [Boris]
- fix Indentation and missing virDomainCryptoDefFree. [Marc]
Changes since v2:
- PATCH 1: modify docs as Martin & Boris's suggestion. [Martin & Boris]
- PATCH 2: add the missing 'ToString'. [Martin]
- PATCH 3: use virAsprintf instead of virBufferAsprintf. [Martin]
remove pointless virBufferCheckError. [Martin]
- rebase on master. [Longpeng]
Changes since v1:
- split patch [Martin]
- rebase on master [Martin]
- add docs/tests/schema [Martin]
- fix typos [Gonglei]
---
Boris Fiuczynski (2):
qemu: virtio-crypto: add ccw support
qemu: virtio-crypto: add test for ccw support
Longpeng(Mike) (6):
docs: schema: Add basic documentation for the virtual
docs: news: Add virtio-crypto devices
conf: Parse virtio-crypto in the domain XML
caps: Add qemu capabilities about virtio-crypto
qemu: Implement support for 'builtin' backend for virtio-crypto
tests: Add testcase for virtio-crypto parsing
docs/formatdomain.html.in | 61 ++++++
docs/news.xml | 10 +
docs/schemas/domaincommon.rng | 30 +++
src/conf/domain_conf.c | 213 ++++++++++++++++++++-
src/conf/domain_conf.h | 32 ++++
src/libvirt_private.syms | 5 +
src/qemu/qemu_alias.c | 20 ++
src/qemu/qemu_alias.h | 3 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_command.c | 130 +++++++++++++
src/qemu/qemu_command.h | 3 +
src/qemu/qemu_domain_address.c | 25 +++
src/qemu/qemu_driver.c | 6 +
src/qemu/qemu_hotplug.c | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 2 +
tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 2 +
.../qemuxml2argv-virtio-crypto-builtin.xml | 26 +++
.../qemuxml2argv-virtio-crypto-ccw.args | 22 +++
.../qemuxml2argv-virtio-crypto-ccw.xml | 16 ++
.../qemuxml2argv-virtio-crypto.args | 22 +++
tests/qemuxml2argvtest.c | 6 +
.../qemuxml2xmlout-virtio-crypto-builtin.xml | 31 +++
tests/qemuxml2xmltest.c | 2 +
25 files changed, 679 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-builtin.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-ccw.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-ccw.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto.args
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-crypto-builtin.xml
--
1.8.3.1
6 years
[libvirt] [PATCH 00/12] Various apparmor related changes (part )
by Christian Ehrhardt
Hi,
this is a continuation of the ongoing effort to feed back Ubuntu apparmor
Delta on libvirt to the community (or to sort out remaining todos or to keep
them distro specific).
In that it is a follow on to:
- https://www.redhat.com/archives/libvir-list/2017-May/msg00630.html
- https://www.redhat.com/archives/libvir-list/2017-May/msg00887.html
I punted those we had discussions on and decided to rework in the last rounds
out of the submission.
But in exchange pulled in some more changes we had that are now ready for
discussion. That way I prepared the next set of 12 changes which I hereby
submit for your consideration into 3.11.
Christian Ehrhardt (3):
apparmor, libvirt-qemu: add default pki path of lbvirt-spice
apparmor, libvirt-qemu: add generic base vfio device
apparmor, libvirt-qemu: qemu won't call qemu-nbd
Jamie Strandboge (5):
apparmor, libvirt-qemu: Allow read access to sysfs system info
apparmor, libvirt-qemu: Allow qemu-block-extra libraries
apparmor, libvirtd: Allow ixr to /var/lib/libvirt/virtd*
apparmor, virt-aa-helper: Allow access to ecryptfs files
apparmor, virt-aa-helper: Allow access to /sys/bus/usb/devices
Serge Hallyn (3):
apparmor, libvirt-qemu: Allow use of sgabios
apparmor, libvirt-qemu: Allow read access to max_mem_regions
apparmor, libvirt-qemu: Allow access to hugepage mounts
Stefan Bader (1):
apparmor, libvirt-qemu: Silence lttng related deny messages
examples/apparmor/libvirt-qemu | 26 +++++++++++++++++++++++-
examples/apparmor/usr.lib.libvirt.virt-aa-helper | 6 ++++++
examples/apparmor/usr.sbin.libvirtd | 4 ++++
3 files changed, 35 insertions(+), 1 deletion(-)
--
2.7.4
6 years, 5 months
[libvirt] [PATCH] qemu: Honour <on_reboot/>
by Michal Privoznik
https://bugzilla.redhat.com/show_bug.cgi?id=1476866
For some reason, we completely ignore <on_reboot/> setting for
domains. The implementation is simply not there. It never was.
However, things are slightly more complicated. QEMU sends us two
RESET events on domain reboot. Fortunately, the event contains
this 'guest' field telling us who initiated the reboot. And since
we don't want to destroy the domain if the reset is initiated by
a user, we have to ignore those events. Whatever, just look at
the code.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_monitor.c | 4 ++--
src/qemu/qemu_monitor.h | 3 ++-
src/qemu/qemu_monitor_json.c | 8 +++++++-
src/qemu/qemu_process.c | 34 ++++++++++++++++++++++++++++++----
5 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index 4c9050aff..d865e67c7 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -233,6 +233,7 @@ struct _qemuDomainObjPrivate {
bool agentError;
bool gotShutdown;
+ bool gotReset;
bool beingDestroyed;
char *pidfile;
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 19082d8bf..8f81a2b28 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -1344,12 +1344,12 @@ qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest)
int
-qemuMonitorEmitReset(qemuMonitorPtr mon)
+qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest)
{
int ret = -1;
VIR_DEBUG("mon=%p", mon);
- QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm);
+ QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm, guest);
return ret;
}
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index 31f7e97ba..8c33f6783 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -134,6 +134,7 @@ typedef int (*qemuMonitorDomainShutdownCallback)(qemuMonitorPtr mon,
void *opaque);
typedef int (*qemuMonitorDomainResetCallback)(qemuMonitorPtr mon,
virDomainObjPtr vm,
+ virTristateBool guest,
void *opaque);
typedef int (*qemuMonitorDomainPowerdownCallback)(qemuMonitorPtr mon,
virDomainObjPtr vm,
@@ -346,7 +347,7 @@ int qemuMonitorEmitEvent(qemuMonitorPtr mon, const char *event,
long long seconds, unsigned int micros,
const char *details);
int qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest);
-int qemuMonitorEmitReset(qemuMonitorPtr mon);
+int qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest);
int qemuMonitorEmitPowerdown(qemuMonitorPtr mon);
int qemuMonitorEmitStop(qemuMonitorPtr mon);
int qemuMonitorEmitResume(qemuMonitorPtr mon);
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index b8a68154a..8a1501ced 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -536,7 +536,13 @@ static void qemuMonitorJSONHandleShutdown(qemuMonitorPtr mon, virJSONValuePtr da
static void qemuMonitorJSONHandleReset(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED)
{
- qemuMonitorEmitReset(mon);
+ bool guest = false;
+ virTristateBool guest_initiated = VIR_TRISTATE_BOOL_ABSENT;
+
+ if (data && virJSONValueObjectGetBoolean(data, "guest", &guest) == 0)
+ guest_initiated = guest ? VIR_TRISTATE_BOOL_YES : VIR_TRISTATE_BOOL_NO;
+
+ qemuMonitorEmitReset(mon, guest_initiated);
}
static void qemuMonitorJSONHandlePowerdown(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 0aecce3b1..889efc7f0 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -478,27 +478,51 @@ qemuProcessFindVolumeQcowPassphrase(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
static int
qemuProcessHandleReset(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
virDomainObjPtr vm,
+ virTristateBool guest_initiated,
void *opaque)
{
virQEMUDriverPtr driver = opaque;
- virObjectEventPtr event;
+ virObjectEventPtr event = NULL;
qemuDomainObjPrivatePtr priv;
virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
+ bool callOnReboot = false;
virObjectLock(vm);
+ priv = vm->privateData;
+
+ /* This is a bit tricky. When a guest does 'reboot' we receive RESET event
+ * twice, both times it's guest initiated. However, if users call 'virsh
+ * reset' we still receive two events but the first one is guest_initiated
+ * = no, the second one is guest_initiated = yes. Therefore, to avoid
+ * executing onReboot action in the latter case we need this complicated
+ * construction. */
+ if (guest_initiated == VIR_TRISTATE_BOOL_NO) {
+ VIR_DEBUG("Ignoring not guest initiated RESET event from domain %s",
+ vm->def->name);
+ priv->gotReset = true;
+ } else if (priv->gotReset && guest_initiated == VIR_TRISTATE_BOOL_YES) {
+ VIR_DEBUG("Ignoring second RESET event from domain %s",
+ vm->def->name);
+ priv->gotReset = false;
+ } else {
+ callOnReboot = true;
+ }
+
event = virDomainEventRebootNewFromObj(vm);
- priv = vm->privateData;
if (priv->agent)
qemuAgentNotifyEvent(priv->agent, QEMU_AGENT_EVENT_RESET);
if (virDomainSaveStatus(driver->xmlopt, cfg->stateDir, vm, driver->caps) < 0)
VIR_WARN("Failed to save status on vm %s", vm->def->name);
+ if (callOnReboot &&
+ guest_initiated == VIR_TRISTATE_BOOL_YES &&
+ vm->def->onReboot == VIR_DOMAIN_LIFECYCLE_DESTROY)
+ qemuProcessShutdownOrReboot(driver, vm);
+
virObjectUnlock(vm);
-
qemuDomainEventQueue(driver, event);
-
virObjectUnref(cfg);
return 0;
}
@@ -555,6 +579,7 @@ qemuProcessFakeReboot(void *opaque)
goto endjob;
}
priv->gotShutdown = false;
+ priv->gotReset = false;
event = virDomainEventLifecycleNewFromObj(vm,
VIR_DOMAIN_EVENT_RESUMED,
VIR_DOMAIN_EVENT_RESUMED_UNPAUSED);
@@ -5320,6 +5345,7 @@ qemuProcessPrepareDomain(virConnectPtr conn,
priv->monError = false;
priv->monStart = 0;
priv->gotShutdown = false;
+ priv->gotReset = false;
VIR_DEBUG("Updating guest CPU definition");
if (qemuProcessUpdateGuestCPU(vm->def, priv->qemuCaps, caps, flags) < 0)
--
2.13.0
6 years, 5 months
[libvirt] [PATCH] qemu: cpu: fix fullCPU to include all emulatable qemu features
by Nikolay Shirokovskiy
On Core i5 650 guest fail to start with error [1] if guest cpu config is taken
from domcapabilities and check is set to partial.
The problem is in qemu caps fullCPU calculation in virQEMUCapsInitHostCPUModel.
It is supposed to include features emulated by qemu and missed on host. Some of
such features may be not included however.
For mentioned cpu host cpu is detected as Westmere and guest cpu as
SandyBridge. x2apic is missed on host and provided by installed qemu. The
feature is not mentioned in guest cpu features explicitly because SandyBridge
model include it. As a result fullCPU does not include x2apic too.
Solution is to expand guest cpu features before updating fullCPU features.
[1] error: the CPU is incompatible with host CPU: Host CPU does not
provide required features: x2apic, tsc-deadline
---
src/qemu/qemu_capabilities.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 9c1eeac..edba716 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3475,6 +3475,7 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
virCPUDefPtr cpu = NULL;
+ virCPUDefPtr cpuExpanded = NULL;
virCPUDefPtr migCPU = NULL;
virCPUDefPtr hostCPU = NULL;
virCPUDefPtr fullCPU = NULL;
@@ -3504,9 +3505,13 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
NULL, NULL)))
goto error;
- for (i = 0; i < cpu->nfeatures; i++) {
- if (cpu->features[i].policy == VIR_CPU_FEATURE_REQUIRE &&
- virCPUDefUpdateFeature(fullCPU, cpu->features[i].name,
+ if (!(cpuExpanded = virCPUDefCopy(cpu)) ||
+ virCPUExpandFeatures(qemuCaps->arch, cpuExpanded) < 0)
+ goto error;
+
+ for (i = 0; i < cpuExpanded->nfeatures; i++) {
+ if (cpuExpanded->features[i].policy == VIR_CPU_FEATURE_REQUIRE &&
+ virCPUDefUpdateFeature(fullCPU, cpuExpanded->features[i].name,
VIR_CPU_FEATURE_REQUIRE) < 0)
goto error;
}
@@ -3528,6 +3533,7 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
virQEMUCapsSetHostModel(qemuCaps, type, cpu, migCPU, fullCPU);
cleanup:
+ virCPUDefFree(cpuExpanded);
virCPUDefFree(hostCPU);
return;
--
1.8.3.1
6 years, 7 months
[libvirt] [[RFC] 0/8] Implement async QEMU event handling in libvirtd.
by Prerna Saxena
As noted in
https://www.redhat.com/archives/libvir-list/2017-May/msg00016.html
libvirt-QEMU driver handles all async events from the main loop.
Each event handling needs the per-VM lock to make forward progress. In
the case where an async event is received for the same VM which has an
RPC running, the main loop is held up contending for the same lock.
This impacts scalability, and should be addressed on priority.
Note that libvirt does have a 2-step deferred handling for a few event
categories, but (1) That is insufficient since blockign happens before
the handler could disambiguate which one needs to be posted to this
other queue.
(2) There needs to be homogeniety.
The current series builds a framework for recording and handling VM
events.
It initializes per-VM event queue, and a global event queue pointing to
events from all the VMs. Event handling is staggered in 2 stages:
- When an event is received, it is enqueued in the per-VM queue as well
as the global queues.
- The global queue is built into the QEMU Driver as a threadpool
(currently with a single thread).
- Enqueuing of a new event triggers the global event worker thread, which
then attempts to take a lock for this event's VM.
- If the lock is available, the event worker runs the function handling
this event type. Once done, it dequeues this event from the global
as well as per-VM queues.
- If the lock is unavailable(ie taken by RPC thread), the event worker
thread leaves this as-is and picks up the next event.
- Once the RPC thread completes, it looks for events pertaining to the
VM in the per-VM event queue. It then processes the events serially
(holding the VM lock) until there are no more events remaining for
this VM. At this point, the per-VM lock is relinquished.
Patch Series status:
Strictly RFC only. No compilation issues. I have not had a chance to
(stress) test it after rebase to latest master.
Note that documentation and test coverage is TBD, since a few open
points remain.
Known issues/ caveats:
- RPC handling time will become non-deterministic.
- An event will only be "notified" to a client once the RPC for same VM completes.
- Needs careful consideration in all cases where a QMP event is used to
"signal" an RPC thread, else will deadlock.
Will be happy to drive more discussion in the community and completely
implement it.
Prerna Saxena (8):
Introduce virObjectTrylock()
QEMU Event handling: Introduce async event helpers in qemu_event.[ch]
Setup global and per-VM event queues. Also initialize per-VM queues
when libvirt reconnects to an existing VM.
Events: Allow monitor to "enqueue" events to a queue. Also introduce a
framework of handlers for each event type, that can be called when
the handler is running an event.
Events: Plumb event handling calls before a domain's APIs complete.
Code refactor: Move helper functions of doCoreDump*, syncNicRxFilter*,
and qemuOpenFile* to qemu_process.[ch]
Fold back the 2-stage event implementation for a few events :
Watchdog, Monitor EOF, Serial changed, Guest panic, Nic RX filter
changed .. into single level.
Initialize the per-VM event queues in context of domain init.
src/Makefile.am | 1 +
src/conf/domain_conf.h | 3 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_conf.h | 4 +
src/qemu/qemu_driver.c | 1710 +++++++----------------------------
src/qemu/qemu_event.c | 317 +++++++
src/qemu/qemu_event.h | 231 +++++
src/qemu/qemu_monitor.c | 592 ++++++++++--
src/qemu/qemu_monitor.h | 80 +-
src/qemu/qemu_monitor_json.c | 291 +++---
src/qemu/qemu_process.c | 2031 ++++++++++++++++++++++++++++++++++--------
src/qemu/qemu_process.h | 88 ++
src/util/virobject.c | 26 +
src/util/virobject.h | 4 +
src/util/virthread.c | 5 +
src/util/virthread.h | 1 +
tests/qemumonitortestutils.c | 2 +-
17 files changed, 3411 insertions(+), 1976 deletions(-)
create mode 100644 src/qemu/qemu_event.c
create mode 100644 src/qemu/qemu_event.h
--
2.9.5
6 years, 8 months
[libvirt] Should we switch to a different JSON library?
by Martin Kletzander
Hi everyone,
so we are using yajl for parsing JSON. However there are some reasons
why we might consider switching to another one:
1) It is basically dead upstream
2) We're just using the lexer part of it
3) We only use it for parsing
4) The are workarounds for it in the code
So I looked at some options and found few other libraries, I only took
those that are widely available (read: I checked if some random
downstream distro has them), however most of them were not very much
usable. Except one. But here's the list of few others that didn't look
that bad either. All are MIT-licensed, try to be thread-safe and
support pkg-config:
- libfastjson [1] - from rsyslog community, optimized for working with
logs, used almost only by rsyslog, it's supposed to
have doxygen docs, they switched to libfastjson
from json-c due to some problems with it
(performance, ref counting bug, ...)
- json-c [2] - looked abandoned until I looked at the proper github
page, "documentation" in doxygen
- Jansson [3] - I really like this one. The API seems very intuitive,
it has nice documentation [4] in readthedocs (and I'm
not talking about the visual style, but how easy is to
find information), it can be used for formatting JSON
in a similar way we are doing it. It has json_auto_t
(optional) type that uses the attribute cleanup for
automatic scope dereference (just in case we want to
use it), it has iterators... did I tell you I like this
one a lot?
What do you (others) think of switching the JSON library? Do you know
about any other projects that could be used considering license,
platform support, etc.? Also feel free to fix any mistakes I might have
posted. I double-checked it, but you know, "trust, but verify".
Have a nice day,
Martin
[1] https://github.com/rsyslog/libfastjson
[2] https://github.com/json-c/json-c
[3] http://www.digip.org/jansson/
[4] https://jansson.readthedocs.io/
6 years, 9 months
[libvirt] [PATCH] qemu: report a nicer error when USB is disabled
by Ján Tomko
If the user tries to define a domain that has
<controller type='usb' model='none'/>
and also some USB devices, we report an error:
error: internal error: No free USB ports
Which is technically still correct for a domain with no USB ports.
Change it to:
USB is disabled for this domain, but USB devices are present in the domain XML
https://bugzilla.redhat.com/show_bug.cgi?id=1347550
---
src/conf/domain_conf.c | 2 +-
src/conf/domain_conf.h | 2 ++
src/libvirt_private.syms | 1 +
src/qemu/qemu_domain_address.c | 7 +++++++
4 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index f3b4dd33d..028fcb5be 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -5116,7 +5116,7 @@ virDomainDiskDefValidate(const virDomainDiskDef *disk)
return 0;
}
-static bool
+bool
virDomainDefHasUSB(const virDomainDef *def)
{
size_t i;
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index bb3b6f0c3..32e191e0a 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2656,6 +2656,8 @@ int virDomainDefPostParse(virDomainDefPtr def,
unsigned int parseFlags,
virDomainXMLOptionPtr xmlopt,
void *parseOpaque);
+bool
+virDomainDefHasUSB(const virDomainDef *def);
int virDomainDefValidate(virDomainDefPtr def,
virCapsPtr caps,
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 5b1bc5e4f..21f226258 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -267,6 +267,7 @@ virDomainDefGetVcpusTopology;
virDomainDefHasDeviceAddress;
virDomainDefHasMemballoon;
virDomainDefHasMemoryHotplug;
+virDomainDefHasUSB;
virDomainDefHasVcpusOffline;
virDomainDefMaybeAddController;
virDomainDefMaybeAddInput;
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 69c0c8bf2..0d565b3ea 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -2644,6 +2644,13 @@ qemuDomainUSBAddressAddHubs(virDomainDefPtr def)
&data,
false));
+ if (data.count && !virDomainDefHasUSB(def)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("USB is disabled for this domain, but USB devices "
+ "are present in the domain XML"));
+ return -1;
+ }
+
if (data.count > available_ports)
hubs_needed = VIR_DIV_UP(data.count - available_ports + 1,
VIR_DOMAIN_USB_HUB_PORTS - 1);
--
2.13.0
6 years, 9 months
