- Devel - libvirt List Archives

[libvirt] [PATCH v3 0/3] Honor blacklist for modprobe command
by John Ferlan 04 Feb '14

04 Feb '14

Rework changes from code review v2 here: http://www.redhat.com/archives/libvir-list/2014-January/msg01473.html v3 changes over v2: * Changed configure.ac for "RMMOD" definition * Use "virKMod*()" instead of "virModprobe*()" for function names * Adjust virKModLoad() to take boolean parameter for using -b or not * Add virKModIsBlacklisted() to perform the blacklist check * Adjust virkmodtest.c to use the virCommandSetDryRun() John Ferlan (3): utils: Introduce functions for modprobe tests: Add test for new virkmod functions Honor blacklist for modprobe command .gitignore | 2 + configure.ac | 6 ++ src/Makefile.am | 1 + src/libvirt_private.syms | 7 ++ src/util/virkmod.c | 182 ++++++++++++++++++++++++++++++++++++++++++++++ src/util/virkmod.h | 34 +++++++++ src/util/virpci.c | 28 +++++--- tests/Makefile.am | 5 ++ tests/virkmodtest.c | 183 +++++++++++++++++++++++++++++++++++++++++++++++ 9 files changed, 439 insertions(+), 9 deletions(-) create mode 100644 src/util/virkmod.c create mode 100644 src/util/virkmod.h create mode 100644 tests/virkmodtest.c -- 1.8.4.2

3 16

[libvirt] [PATCH] build: Fix 'make rpm' in VPATH with wireshark
by Martin Kletzander 04 Feb '14

04 Feb '14

Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- tools/wireshark/Makefile.am | 1 + tools/wireshark/src/Makefile.am | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/wireshark/Makefile.am b/tools/wireshark/Makefile.am index b6fa57c..28e6ed8 100644 --- a/tools/wireshark/Makefile.am +++ b/tools/wireshark/Makefile.am @@ -20,3 +20,4 @@ if WITH_WIRESHARK_DISSECTOR SUBDIRS = src endif WITH_WIRESHARK_DISSECTOR +EXTRA_DIST = util/genxdrstub.pl util/make-dissector-reg diff --git a/tools/wireshark/src/Makefile.am b/tools/wireshark/src/Makefile.am index afe9975..44f22be 100644 --- a/tools/wireshark/src/Makefile.am +++ b/tools/wireshark/src/Makefile.am @@ -21,7 +21,7 @@ INCLUDES = -I$(top_srcdir) ws_plugin_LTLIBRARIES = libvirt.la -libvirt_la_SOURCES = packet-libvirt.c plugin.c +libvirt_la_SOURCES = packet-libvirt.h packet-libvirt.c plugin.c libvirt_la_CPPFLAGS = $(WS_DISSECTOR_CPPFLAGS) libvirt_la_LDFLAGS = -avoid-version -module -- 1.8.5.3

4 4

[libvirt] [PATCH] event: improve public API docs
by Eric Blake 04 Feb '14

04 Feb '14

Since libvirt 0.9.3, the entire virevent.c file has been a public API, so improve the documentation in this file. Also, fix a potential core dump - it could only be triggered by bogus use of the API and would only affect the caller (not libvirtd), but we might as well be nice. * src/libvirt.c (virConnectDomainEventRegister) (virConnectDomainEventRegisterAny) (virConnectNetworkEventRegisterAny): Document event loop requirement. * src/util/virevent.c (virEventAddHandle, virEventRemoveHandle) (virEventAddTimeout, virEventRemoveTimeout): Likewise. (virEventUpdateHandle, virEventUpdateTimeout): Likewise, and avoid core dump if caller didn't register handler. (virEventRunDefaultImpl): Expand example, and set up code block in html docs. (virEventRegisterImpl, virEventRegisterDefaultImpl): Document more on the use of the event loop. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- src/libvirt.c | 24 ++++++++++------ src/util/virevent.c | 82 +++++++++++++++++++++++++++++++++++------------------ 2 files changed, 70 insertions(+), 36 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 66841c8..f43718d 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -16121,11 +16121,13 @@ error: * @freecb: optional function to deallocate opaque when not used anymore * * Adds a callback to receive notifications of domain lifecycle events - * occurring on a connection + * occurring on a connection. This function requires that an event loop + * has been previously registered with virEventRegisterImpl() or + * virEventRegisterDefaultImpl(). * * Use of this method is no longer recommended. Instead applications * should try virConnectDomainEventRegisterAny() which has a more flexible - * API contract + * API contract. * * The virDomainPtr object handle passed into the callback upon delivery * of an event is only valid for the duration of execution of the callback. @@ -16134,7 +16136,7 @@ error: * The reference can be released once the object is no longer required * by calling virDomainFree. * - * Returns 0 on success, -1 on failure + * Returns 0 on success, -1 on failure. */ int virConnectDomainEventRegister(virConnectPtr conn, @@ -19064,10 +19066,12 @@ error: * @freecb: optional function to deallocate opaque when not used anymore * * Adds a callback to receive notifications of arbitrary domain events - * occurring on a domain. + * occurring on a domain. This function requires that an event loop + * has been previously registered with virEventRegisterImpl() or + * virEventRegisterDefaultImpl(). * * If @dom is NULL, then events will be monitored for any domain. If @dom - * is non-NULL, then only the specific domain will be monitored + * is non-NULL, then only the specific domain will be monitored. * * Most types of event have a callback providing a custom set of parameters * for the event. When registering an event, it is thus necessary to use @@ -19085,7 +19089,7 @@ error: * for the callback. To unregister a callback, this callback ID should * be passed to the virConnectDomainEventDeregisterAny() method. * - * Returns a callback identifier on success, -1 on failure + * Returns a callback identifier on success, -1 on failure. */ int virConnectDomainEventRegisterAny(virConnectPtr conn, @@ -19183,10 +19187,12 @@ error: * @freecb: optional function to deallocate opaque when not used anymore * * Adds a callback to receive notifications of arbitrary network events - * occurring on a network. + * occurring on a network. This function requires that an event loop + * has been previously registered with virEventRegisterImpl() or + * virEventRegisterDefaultImpl(). * * If @net is NULL, then events will be monitored for any network. If @net - * is non-NULL, then only the specific network will be monitored + * is non-NULL, then only the specific network will be monitored. * * Most types of event have a callback providing a custom set of parameters * for the event. When registering an event, it is thus necessary to use @@ -19204,7 +19210,7 @@ error: * for the callback. To unregister a callback, this callback ID should * be passed to the virConnectNetworkEventDeregisterAny() method. * - * Returns a callback identifier on success, -1 on failure + * Returns a callback identifier on success, -1 on failure. */ int virConnectNetworkEventRegisterAny(virConnectPtr conn, diff --git a/src/util/virevent.c b/src/util/virevent.c index fde29a2..0c94946 100644 --- a/src/util/virevent.c +++ b/src/util/virevent.c @@ -37,6 +37,16 @@ static virEventAddTimeoutFunc addTimeoutImpl = NULL; static virEventUpdateTimeoutFunc updateTimeoutImpl = NULL; static virEventRemoveTimeoutFunc removeTimeoutImpl = NULL; + +/***************************************************** + * + * Below this point are *PUBLIC* APIs for event + * loop integration with applications using libvirt. + * These API contracts cannot be changed. + * + *****************************************************/ + + /** * virEventAddHandle: * @@ -46,10 +56,12 @@ static virEventRemoveTimeoutFunc removeTimeoutImpl = NULL; * @opaque: user data to pass to callback * @ff: callback to free opaque when handle is removed * - * Register a callback for monitoring file handle events. + * Register a callback for monitoring file handle events. This function + * requires that an event loop has previously been registered with + * virEventRegisterImpl() or virEventRegisterDefaultImpl(). * * Returns -1 if the file handle cannot be registered, otherwise a handle - * watch number to be used for updating and unregistering for events + * watch number to be used for updating and unregistering for events. */ int virEventAddHandle(int fd, @@ -70,14 +82,17 @@ virEventAddHandle(int fd, * @watch: watch whose file handle to update * @events: bitset of events to watch from virEventHandleType constants * - * Change event set for a monitored file handle. + * Change event set for a monitored file handle. This function + * requires that an event loop has previously been registered with + * virEventRegisterImpl() or virEventRegisterDefaultImpl(). * - * Will not fail if fd exists + * Will not fail if fd exists. */ void virEventUpdateHandle(int watch, int events) { - updateHandleImpl(watch, events); + if (updateHandleImpl) + updateHandleImpl(watch, events); } /** @@ -85,7 +100,9 @@ virEventUpdateHandle(int watch, int events) * * @watch: watch whose file handle to remove * - * Unregister a callback from a file handle. + * Unregister a callback from a file handle. This function + * requires that an event loop has previously been registered with + * virEventRegisterImpl() or virEventRegisterDefaultImpl(). * * Returns -1 if the file handle was not registered, 0 upon success. */ @@ -106,7 +123,9 @@ virEventRemoveHandle(int watch) * @opaque: user data to pass to callback * @ff: callback to free opaque when timeout is removed * - * Register a callback for a timer event. + * Register a callback for a timer event. This function + * requires that an event loop has previously been registered with + * virEventRegisterImpl() or virEventRegisterDefaultImpl(). * * Setting timeout to -1 will disable the timer. Setting the timeout * to zero will cause it to fire on every event loop iteration. @@ -132,17 +151,20 @@ virEventAddTimeout(int timeout, * @timer: timer id to change * @timeout: time between events in milliseconds * - * Change frequency for a timer. + * Change frequency for a timer. This function + * requires that an event loop has previously been registered with + * virEventRegisterImpl() or virEventRegisterDefaultImpl(). * * Setting frequency to -1 will disable the timer. Setting the frequency * to zero will cause it to fire on every event loop iteration. * - * Will not fail if timer exists + * Will not fail if timer exists. */ void virEventUpdateTimeout(int timer, int timeout) { - updateTimeoutImpl(timer, timeout); + if (updateTimeoutImpl) + updateTimeoutImpl(timer, timeout); } /** @@ -150,7 +172,9 @@ virEventUpdateTimeout(int timer, int timeout) * * @timer: the timer id to remove * - * Unregister a callback for a timer. + * Unregister a callback for a timer. This function + * requires that an event loop has previously been registered with + * virEventRegisterImpl() or virEventRegisterDefaultImpl(). * * Returns -1 if the timer was not registered, 0 upon success. */ @@ -164,14 +188,6 @@ virEventRemoveTimeout(int timer) } -/***************************************************** - * - * Below this point are 3 *PUBLIC* APIs for event - * loop integration with applications using libvirt. - * These API contracts cannot be changed. - * - *****************************************************/ - /** * virEventRegisterImpl: * @addHandle: the callback to add fd handles @@ -186,9 +202,14 @@ virEventRemoveTimeout(int timer) * to integrate with the libglib2 event loop, or libevent * or the QT event loop. * + * Use of the virEventAddHandle() and similar APIs require that the + * corresponding handler be registered. Use of the + * virConnectDomainEventRegisterAny() and similar APIs requires that + * the three timeout handlers be registered. + * * If an application does not need to integrate with an * existing event loop implementation, then the - * virEventRegisterDefaultImpl method can be used to setup + * virEventRegisterDefaultImpl() method can be used to setup * the generic libvirt implementation. */ void virEventRegisterImpl(virEventAddHandleFunc addHandle, @@ -220,9 +241,12 @@ void virEventRegisterImpl(virEventAddHandleFunc addHandle, * not have a need to integrate with an external event * loop impl. * - * Once registered, the application has to invoke virEventRunDefaultImpl in + * Once registered, the application has to invoke virEventRunDefaultImpl() in * a loop to process events. Failure to do so may result in connections being - * closed unexpectedly as a result of keepalive timeout. + * closed unexpectedly as a result of keepalive timeout. The default + * event loop fully supports handle and and timeout events, but only + * wakes up on events registered by libvirt API calls such as + * virEventAddHandle() or virConnectDomainEventRegisterAny(). * * Returns 0 on success, -1 on failure. */ @@ -255,14 +279,18 @@ int virEventRegisterDefaultImpl(void) * * Run one iteration of the event loop. Applications * will generally want to have a thread which invokes - * this method in an infinite loop + * this method in an infinite loop. Furthermore, it is wise + * to set up a pipe-to-self handler (via virEventAddHandle()) + * or a timeout (via virEventAddTimeout()) before calling this + * function, as it will block forever if there are no + * registered events. * - * static bool quit = false; + * static bool quit = false; * - * while (!quit) { - * if (virEventRunDefaultImpl() < 0) + * while (!quit) { + * if (virEventRunDefaultImpl() < 0) * ...print error... - * } + * } * * Returns 0 on success, -1 on failure. */ -- 1.8.4.2

4 8

[libvirt] [RFC PATCH] libvirt support to force convergence of live guest migration
by Chegu Vinod 04 Feb '14

04 Feb '14

Busy enterprise workloads hosted on large sized VM's tend to dirty memory faster than the transfer rate achieved via live guest migration. Despite some good recent improvements (& using dedicated 10Gig NICs between hosts) the live migration may NOT converge. Recently support was added in qemu (version 1.6) to allow a user to choose if they wish to force convergence of their migration via a new migration capability : "auto-converge". This feature allows for qemu to auto-detect lack of convergence and trigger a throttle-down of the VCPUs. This RFC patch includes the libvirt support needed to trigger this feature. (Testing is still in progress) Signed-off-by: Chegu Vinod <chegu_vinod(a)hp.com> --- include/libvirt/libvirt.h.in | 1 + src/qemu/qemu_migration.c | 44 ++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_migration.h | 1 + src/qemu/qemu_monitor.c | 2 +- src/qemu/qemu_monitor.h | 1 + tools/virsh-domain.c | 7 ++++++ 6 files changed, 55 insertions(+), 1 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index 146a59b..13b0bfc 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -1192,6 +1192,7 @@ typedef enum { VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */ VIR_MIGRATE_COMPRESSED = (1 << 11), /* compress data during migration */ VIR_MIGRATE_ABORT_ON_ERROR = (1 << 12), /* abort migration on I/O errors happened during migration */ + VIR_MIGRATE_AUTO_CONVERGE = (1 << 13), /* force auto-convergence during during migration */ } virDomainMigrateFlags; diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index e87ea85..8cc0c56 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1565,6 +1565,40 @@ cleanup: } static int +qemuMigrationSetAutoConverge(virQEMUDriverPtr driver, + virDomainObjPtr vm, + enum qemuDomainAsyncJob job) +{ + qemuDomainObjPrivatePtr priv = vm->privateData; + int ret; + + if (qemuDomainObjEnterMonitorAsync(driver, vm, job) < 0) + return -1; + + ret = qemuMonitorGetMigrationCapability( + priv->mon, + QEMU_MONITOR_MIGRATION_CAPS_AUTO_CONVERGE); + + if (ret < 0) { + goto cleanup; + } else if (ret == 0) { + virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s", + _("Auto-Converge migration is not supported by " + "QEMU binary")); + ret = -1; + goto cleanup; + } + + ret = qemuMonitorSetMigrationCapability( + priv->mon, + QEMU_MONITOR_MIGRATION_CAPS_AUTO_CONVERGE); + +cleanup: + qemuDomainObjExitMonitor(driver, vm); + return ret; +} + +static int qemuMigrationWaitForSpice(virQEMUDriverPtr driver, virDomainObjPtr vm) { @@ -2389,6 +2423,11 @@ qemuMigrationPrepareAny(virQEMUDriverPtr driver, QEMU_ASYNC_JOB_MIGRATION_IN) < 0) goto stop; + if (flags & VIR_MIGRATE_AUTO_CONVERGE && + qemuMigrationSetAutoConverge(driver, vm, + QEMU_ASYNC_JOB_MIGRATION_IN) < 0) + goto stop; + if (mig->lockState) { VIR_DEBUG("Received lockstate %s", mig->lockState); VIR_FREE(priv->lockState); @@ -3181,6 +3220,11 @@ qemuMigrationRun(virQEMUDriverPtr driver, QEMU_ASYNC_JOB_MIGRATION_OUT) < 0) goto cleanup; + if (flags & VIR_MIGRATE_AUTO_CONVERGE && + qemuMigrationSetAutoConverge(driver, vm, + QEMU_ASYNC_JOB_MIGRATION_OUT) < 0) + goto cleanup; + if (qemuDomainObjEnterMonitorAsync(driver, vm, QEMU_ASYNC_JOB_MIGRATION_OUT) < 0) goto cleanup; diff --git a/src/qemu/qemu_migration.h b/src/qemu/qemu_migration.h index cafa2a2..c4258a1 100644 --- a/src/qemu/qemu_migration.h +++ b/src/qemu/qemu_migration.h @@ -39,6 +39,7 @@ VIR_MIGRATE_UNSAFE | \ VIR_MIGRATE_OFFLINE | \ VIR_MIGRATE_COMPRESSED | \ + VIR_MIGRATE_AUTO_CONVERGE | \ VIR_MIGRATE_ABORT_ON_ERROR) /* All supported migration parameters and their types. */ diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 1514715..780a29a 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -118,7 +118,7 @@ VIR_ENUM_IMPL(qemuMonitorMigrationStatus, VIR_ENUM_IMPL(qemuMonitorMigrationCaps, QEMU_MONITOR_MIGRATION_CAPS_LAST, - "xbzrle") + "xbzrle", "auto-converge") VIR_ENUM_IMPL(qemuMonitorVMStatus, QEMU_MONITOR_VM_STATUS_LAST, diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index eabf000..95e70ab 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -440,6 +440,7 @@ int qemuMonitorGetSpiceMigrationStatus(qemuMonitorPtr mon, typedef enum { QEMU_MONITOR_MIGRATION_CAPS_XBZRLE, + QEMU_MONITOR_MIGRATION_CAPS_AUTO_CONVERGE, QEMU_MONITOR_MIGRATION_CAPS_LAST } qemuMonitorMigrationCaps; diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 1fe138c..d94a81b 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -8532,6 +8532,10 @@ static const vshCmdOptDef opts_migrate[] = { .type = VSH_OT_BOOL, .help = N_("compress repeated pages during live migration") }, + {.name = "auto-converge", + .type = VSH_OT_BOOL, + .help = N_("force auto convergence during live migration") + }, {.name = "abort-on-error", .type = VSH_OT_BOOL, .help = N_("abort on soft errors during migration") @@ -8676,6 +8680,9 @@ doMigrate(void *opaque) if (vshCommandOptBool(cmd, "compressed")) flags |= VIR_MIGRATE_COMPRESSED; + if (vshCommandOptBool(cmd, "auto-converge")) + flags |= VIR_MIGRATE_AUTO_CONVERGE; + if (vshCommandOptBool(cmd, "offline")) { flags |= VIR_MIGRATE_OFFLINE; } -- 1.7.1

4 7

[libvirt] [PATCH v1 0/2] Network hooks
by Michal Privoznik 04 Feb '14

04 Feb '14

With the latest noise I made on the list with QoS I'm coming forward with this idea. Network hooks can fill some holes in our functionality. For instance if somebody is willing to set a QoS that is not covered by libvirt, or just want to insert some additional iptables rules, etc. You name it. Michal Privoznik (2): networkStartNetwork: Be more verbose network: Introduce start and shutdown hooks docs/hooks.html.in | 43 ++++++++++++++++++++---------- src/network/bridge_driver.c | 64 +++++++++++++++++++++++++++++++++------------ src/util/virhook.c | 10 ++++++- src/util/virhook.h | 8 ++++++ 4 files changed, 94 insertions(+), 31 deletions(-) -- 1.8.5.2

3 7

[libvirt] [PATCH v2 00/18] LXC configuration conversion to domain XML
by Cédric Bosdonnat 04 Feb '14

04 Feb '14

This new version of the patchset, fixes all comments from Daniel. It also adds two more commits: one extending virConf to use it later in lxc_native.c and one for some documentation on the new feature and its limitations. Several RFEs have been filesd for this patchset: they are mentioned in the appropriate commit log, and I still hope to be able to provide patches for them later. Cédric Bosdonnat (18): Improve virConf parse to handle LXC config format LXC driver: started implementing connectDomainXMLFromNative LXC from native: import rootfs LXC from native: migrate fstab and lxc.mount.entry LXC from native: implement no network conversion LXC from native: migrate veth network configuration LXC from native: convert phys network types to net hostdev devices LXC from native: convert lxc.tty to console devices LXC from native: convert macvlan network configuration LXC from native: convert lxc.id_map into <idmap> LXC from native: migrate memory tuning LXC from native: map lxc.cgroup.cpu.* LXC from native: map lxc.cgroup.cpuset.* LXC from native: add lxc.cgroup.blkio.* mapping LXC from native: map lxc.arch to /domain/os/type@arch LXC from native: map block filesystems LXC from native: map vlan network type LXC: added some doc on domxml-from-native with mention of limitations .gitignore | 1 + docs/drvlxc.html.in | 34 +- po/POTFILES.in | 1 + src/Makefile.am | 1 + src/libvirt_private.syms | 1 + src/lxc/lxc_container.c | 2 +- src/lxc/lxc_container.h | 2 + src/lxc/lxc_driver.c | 31 + src/lxc/lxc_native.c | 883 +++++++++++++++++++++ src/lxc/lxc_native.h | 32 + src/util/virconf.c | 46 +- src/util/virconf.h | 10 + tests/Makefile.am | 7 +- tests/lxcconf2xmldata/lxcconf2xml-blkiotune.config | 7 + tests/lxcconf2xmldata/lxcconf2xml-blkiotune.xml | 35 + .../lxcconf2xmldata/lxcconf2xml-cpusettune.config | 6 + tests/lxcconf2xmldata/lxcconf2xml-cpusettune.xml | 27 + tests/lxcconf2xmldata/lxcconf2xml-cputune.config | 7 + tests/lxcconf2xmldata/lxcconf2xml-cputune.xml | 29 + tests/lxcconf2xmldata/lxcconf2xml-fstab.config | 37 + tests/lxcconf2xmldata/lxcconf2xml-idmap.config | 5 + tests/lxcconf2xmldata/lxcconf2xml-idmap.xml | 28 + .../lxcconf2xml-macvlannetwork.config | 13 + .../lxcconf2xmldata/lxcconf2xml-macvlannetwork.xml | 26 + tests/lxcconf2xmldata/lxcconf2xml-memtune.config | 10 + tests/lxcconf2xmldata/lxcconf2xml-memtune.xml | 29 + .../lxcconf2xmldata/lxcconf2xml-nonenetwork.config | 4 + tests/lxcconf2xmldata/lxcconf2xml-nonenetwork.xml | 21 + tests/lxcconf2xmldata/lxcconf2xml-nonetwork.config | 3 + tests/lxcconf2xmldata/lxcconf2xml-nonetwork.xml | 24 + .../lxcconf2xmldata/lxcconf2xml-physnetwork.config | 6 + tests/lxcconf2xmldata/lxcconf2xml-physnetwork.xml | 26 + tests/lxcconf2xmldata/lxcconf2xml-simple.config | 41 + tests/lxcconf2xmldata/lxcconf2xml-simple.xml | 41 + .../lxcconf2xmldata/lxcconf2xml-vlannetwork.config | 12 + tests/lxcconf2xmldata/lxcconf2xml-vlannetwork.xml | 26 + tests/lxcconf2xmltest.c | 131 +++ 37 files changed, 1640 insertions(+), 5 deletions(-) create mode 100644 src/lxc/lxc_native.c create mode 100644 src/lxc/lxc_native.h create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-blkiotune.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-blkiotune.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cpusettune.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cpusettune.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cputune.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-cputune.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-fstab.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-idmap.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-idmap.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-macvlannetwork.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-macvlannetwork.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-memtune.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-memtune.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonenetwork.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonenetwork.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonetwork.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-nonetwork.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-physnetwork.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-physnetwork.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-simple.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-simple.xml create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-vlannetwork.config create mode 100644 tests/lxcconf2xmldata/lxcconf2xml-vlannetwork.xml create mode 100644 tests/lxcconf2xmltest.c -- 1.8.5.2

3 38

[libvirt] [libvirt-glib 1/5] gconfig: Fix gvir_config_domain_os_get_boot_devices() API doc
by Christophe Fergeau 04 Feb '14

04 Feb '14

The elements of the returned list are integer enum values, so they cannot be unreffed. --- libvirt-gconfig/libvirt-gconfig-domain-os.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libvirt-gconfig/libvirt-gconfig-domain-os.c b/libvirt-gconfig/libvirt-gconfig-domain-os.c index 03c8a85..b922a0e 100644 --- a/libvirt-gconfig/libvirt-gconfig-domain-os.c +++ b/libvirt-gconfig/libvirt-gconfig-domain-os.c @@ -267,8 +267,7 @@ static gboolean add_boot_device(xmlNodePtr node, gpointer opaque) * @os: a #GVirConfigDomainOs * * Gets the list of devices attached to @os. The returned list should be - * freed with g_list_free(), after its elements have been unreffed with - * g_object_unref(). + * freed with g_list_free(). * * Returns: (element-type LibvirtGConfig.DomainOsBootDevice) (transfer full): * a newly allocated #GList of #GVirConfigDomainOsBootDevice. -- 1.8.4.2

2 12

[libvirt] [PATCH] The numa node numbers can be non-sequential.
by Shivaprasad G Bhat 04 Feb '14

04 Feb '14

On PowerNV platform the numa node numbers can be non-sequential, #numactl --hardware node distances: node 0 1 16 17 0: 10 40 40 40 1: 40 10 40 40 16: 40 40 10 40 17: 40 40 40 10 The numa node number is used as index and vice versa which can cause the libvirt to crash. Signed-off-by: Shivaprasad G Bhat <sbhat(a)linux.vnet.ibm.com> Signed-off-by: Pradipta Kumar Banerjee <bpradip(a)in.ibm.com> --- src/conf/capabilities.c | 12 ++++++++++-- src/qemu/qemu_driver.c | 5 +++-- src/qemu/qemu_process.c | 2 +- 3 files changed, 14 insertions(+), 5 deletions(-) diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c index 726ec3f..78f65cb 100644 --- a/src/conf/capabilities.c +++ b/src/conf/capabilities.c @@ -1000,10 +1000,18 @@ virCapabilitiesGetCpusForNode(virCapsPtr caps, size_t node, virBitmapPtr cpumask) { - virCapsHostNUMACellPtr cell = caps->host.numaCell[node]; + virCapsHostNUMACellPtr cell = NULL; size_t cpu; + size_t index; + /* The numa node numbers can be non-contiguous. Ex: 0,1,16,17. */ + for (index = 0; index < caps->host.nnumaCell; index++) { + if (caps->host.numaCell[index]->num == node) { + cell = caps->host.numaCell[index]; + break; + } + } - for (cpu = 0; cpu < cell->ncpus; cpu++) { + for (cpu = 0; cell && cpu < cell->ncpus; cpu++) { if (virBitmapSetBit(cpumask, cell->cpus[cpu].id) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Cpu '%u' in node '%zu' is out of range " diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 6b3825a..ae36fbe 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -8532,12 +8532,13 @@ qemuDomainSetNumaParamsLive(virDomainObjPtr vm, for (i = 0; i < caps->host.nnumaCell; i++) { bool result; - if (virBitmapGetBit(nodeset, i, &result) < 0) { + virCapsHostNUMACellPtr cell = caps->host.numaCell[i]; + if (virBitmapGetBit(nodeset, cell->num, &result) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to get cpuset bit values")); goto cleanup; } - if (result && (virBitmapSetBit(temp_nodeset, i) < 0)) { + if (result && (virBitmapSetBit(temp_nodeset, cell->num) < 0)) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to set temporary cpuset bit values")); goto cleanup; diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 8bcd98e..c28f84d 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2002,7 +2002,7 @@ qemuPrepareCpumap(virQEMUDriverPtr driver, size_t j; int cur_ncpus = caps->host.numaCell[i]->ncpus; bool result; - if (virBitmapGetBit(nodemask, i, &result) < 0) { + if (virBitmapGetBit(nodemask, caps->host.numaCell[i]->num, &result) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to convert nodeset to cpuset")); virBitmapFree(cpumap);

2 1

[libvirt] [PATCH] qemu: be sure we're using the updated value of backend during hotplug
by Laine Stump 04 Feb '14

04 Feb '14

Probable fix for https://bugzilla.redhat.com/show_bug.cgi?id=1056360 commit f094aaac changed qemuPrepareHostdevPCIDevices() such that it may modify the "backend" (vfio vs. legacy kvm) setting in the virHostdevDef. However, qemuDomainAttachHostPciDevice() (used by hotplug) copies the backend setting into a local *before* calling qemuPrepareHostdevPCIDevices(), and then later makes a decision based on that pre-change value. The result is that, if the backend had been set to "default" (i.e. not specified in the config) and was later updated to "VFIO" by qemuPrepareHostdevPCIDevices(), the qemu process' MacMemLock is not increased (as is required for VFIO device assignment). This patch delays making the local copy of backend until after its potential modification. --- src/qemu/qemu_hotplug.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 4315df2..4a885d2 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1,7 +1,7 @@ /* * qemu_hotplug.h: QEMU device hotplug management * - * Copyright (C) 2006-2013 Red Hat, Inc. + * Copyright (C) 2006-2014 Red Hat, Inc. * Copyright (C) 2006 Daniel P. Berrange * * This library is free software; you can redistribute it and/or @@ -1152,7 +1152,7 @@ qemuDomainAttachHostPciDevice(virQEMUDriverPtr driver, bool releaseaddr = false; bool teardowncgroup = false; bool teardownlabel = false; - int backend = hostdev->source.subsys.u.pci.backend; + int backend; unsigned long long memKB; if (VIR_REALLOC_N(vm->def->hostdevs, vm->def->nhostdevs + 1) < 0) @@ -1162,6 +1162,9 @@ qemuDomainAttachHostPciDevice(virQEMUDriverPtr driver, &hostdev, 1, priv->qemuCaps) < 0) return -1; + /* this could have been changed by qemuPrepareHostdevPCIDevices */ + backend = hostdev->source.subsys.u.pci.backend; + switch ((virDomainHostdevSubsysPciBackendType) backend) { case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO: if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) { -- 1.8.5.3

2 1

[libvirt] [PATCH] Write up the project governance process
by Daniel P. Berrange 04 Feb '14

04 Feb '14

The project has historically operated as a meritocratic consensus based community. Formally document what has always been an unwritten assumption amongst the community participants. Also include an explicit code of conduct to prempt any potential, but unlikely, future problems. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/governance.html.in | 292 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 292 insertions(+) create mode 100644 docs/governance.html.in At FOSDEM this past weekend I was asked what the libvirt governance process was. While I believe our community members already understand all this, and it can be infered from behaviour on lists, it will help future new contributors to understand how we operate if we actually document it. This is likely to be particularly helpful for other companies wondering how to get involved in the libvirt project. diff --git a/docs/governance.html.in b/docs/governance.html.in new file mode 100644 index 0000000..8bc4e51 --- /dev/null +++ b/docs/governance.html.in @@ -0,0 +1,292 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Project governance</h1> + + <ul id="toc"></ul> + + <p> + The libvirt project operates as a meritocratic, consensus-based community. + Anyone with an interest in the project can join the community, contributing + to the ongoing development of the project's work. This pages describes how + that participation takes place and how contributors earn merit, and thus + influence, within the community. + </p> + + <h2><a name="codeofconduct">Code of conduct</a></h2> + + <p> + The libvirt project community covers people from a wide variety of + countries, backgrounds and positions. This global diversity is a great + strength of the project, but can also lead to communication issues, + which may in turn cause unhappiness. To maximise happiness of the + project community taken as a whole, all members (whether users, + contributors or committers) are expected to abide by the project's + code of conduct. At a high level the code can be summarized as + <em>"be excellant to each other"</em>. Expanding on this + </p> + + <ul> + <li><strong>Be respectful:</strong> disagreements between people are to + be expected and are usually the sign of healthy debate and engagement. + Disagreements can lead to frustration and even anger for some members. + Turning to personal insults, intimidation or threatening behaviour does + not improve the situation though. Participants should thus take care to + ensure all communications / interactions stay professional at all times.</li> + + <li><strong>Be considerate:</strong> remember that the community has members + with a diverse background many of whom have English as a second language. + What might appear impolite, may simply be a result of a lack of knowledge + of the English language. Bear in mind that actions will have an impact + on other community members and the project as a whole, so take potential + consequences into account before persuing a course of action.</li> + + <li><strong>Be forgiving:</strong> humans are fallible and as such prone + to make mistakes and inexplicably change their positions at times. Don't + assume that other members are acting with malicious intent. Be prepared + to forgive people who make mistakes and assist each other in learning + from them. Playing a blame game doesn't help anyone.</li> + </ul> + + <h2><a name="roles">Roles and responsibilities</a></h2> + + <h3><a href="users">Users</a></h3> + + <p> + The users are anyone who has a need for the output of the project. + There are no rules or requirements to become a user of libvirt. Even + if the software does not yet work on their OS platform, a person can + be considered a potential future user and welcomed to participate. + </p> + + <p> + Participation by users is key to ensuring the project moves in the + right direction, satisfying their real world needs. Users are + encouraged in participate in the broader libvirt community in any + number of ways: + </p> + + <ul> + <li>Evangelism: spread the word about what libvirt is doing, how it + helps solve your problems. This can be via blog articles, social + media postings, video blogs, user group / conference presentations + and any other method of diseminating information</li> + <li>Feedback: let the developers know about what does and does not + work with the project. Talk to developers on the project's + IRC channel and mailing list, or find them at conferences. Tell + them what gaps the project has or where they should look for + future development</li> + <li>Moral support: developers live for recognition of the positive + impact their work has on users' lives. Give thanks to the developers + when evangelising the project, or when meeting them at user groups, + conferences, etc.</li> + </ul> + + <p> + The above is not an exhaustive list of things users can do to + participate in the project. Further ideas and suggestions are + welcome. Users are encouraged to take their participation + further and become contributors to the project in any of the + ways listed in the next section. + </p> + + <h3><a name="contributors">Contributors</a></h3> + + <p> + The contributors are community members who have some concrete impact + to the ongoing development of the project. There are many ways in which + members can contribute, with no requirement to be a software engineer. + Many users can in fact consider themselves contributors merely by + engaging in evangelism for the project. + </p> + + <ul> + <li>Bug reporting: improve the quality of the project by reporting + any problems found either to the project's own bug tracker, or to + that of the OS vendor shipping the libvirt code.</li> + <li>User help: join the IRC channel or mailing list to assist or advice + other users in troubleshooting the problems they face.</li> + <li>Feature requests: help set the direction for future work by + reporting details of features which are missing to the project's + own bug tracker or mailing lists.</li> + <li>Graphical design: contribute to the development of the project's + websites / wiki brand with improved graphics, styling or layout.</li> + <li>Code development: write and submit patches to address bugs or implement + new features</li> + <li>Architectural design: improve the usefulness of the project + by providing feedback on the design of proposed features, to + ensure they satisfy the broadest applicable needs and an survive + the long term</li> + <li>Code review: look at patches which are submitted and critique + the code to identify bugs, potential design problems or other + issues which should be addressed before the code is accepted</li> + <li>Documentation: contribute to content on personal blogs, the + website, wiki, code comments, or any of the formal documentation + efforts.</li> + <li>Translation: join the Fedora transifex community to improve the + quality of translations needed by the libvirt project.</li> + </ul> + + <p> + The above is not an exhaustive list of things members can do to + contribute to the project. Further ideas and suggestions are + welcome. + </p> + + <p> + There are no special requirements to becoming a contributor other + than having the interest and ability to provide a contribution. The + libvirt project <strong>does not require</strong> any + <em>"Contributor License Agreement"</em> + to be signed prior to engagement with the community. + </p> + + <p> + In making a contribution to the project, the community member is + implicitly stating that they accept the terms of the license under + which the work they are contributing to is distributed. They are + also implicitly stating that they have the legal right to make the + contribution, if doing so on behalf of a broader organization / + company. Most of the project's code is distributed under the GNU + Lesser General Public License, version 2 or later. Details of the + exact license under which contributions will be presumed to be + covered are found in the source repositories, or website in question. + </p> + + <h3><a name="committers">Committers</a></h3> + + <p> + The committers are the subset of contributors who have direct access + to commit code to the project's primary source code repositories, which + are currently using the GIT software. The committers are chosen based + on the quality of their contributions over a period of time. This includes + both the quality of code they submit, as well as the quality of reviews + they provide on other contributors' submissions and a demonstration that + they understand day-to-day operation of the projet and its goals. There + is no minimum level of contribution required in order to become a committer, + though 2-3 months worth of quality contribution would be a rough guide. + </p> + + <p> + There are no special requirements to becoming a committer other than to + have shown a willingness and ability to contribute to the project over + an extended period of time. Proposals for elevating contributors to + committers are typically made by existing comitters, though contributors + are also welcome to make proposals. The decision to approve the elevation + of a contributor to a committer is made through "rough consensus" between + the existing committers. + </p> + + <p> + The aim in elevating contributors to committers is to ensure that there + is a broad base of experience and expertize across all areas of the + project's work. Committers are not required to have knowledge across + all areas of the project's work. While an approved committer has the + technical ability to commit code to any area of the project, by convention + they will only commit to areas they feel themselves to be qualified to + evaluate the contribution. If in doubt, committers will defer to the + opinion of other committers with greater expertize in an area. + </p> + + <p> + The committers hold the ultimate control over what contributions are + accepted by the project, however, this does not mean they have the + right to do whatever they want. Where there is debate and disagreement + between contributors, committers are expected to look at the issues with + an unbiased point of view and help achieve a "rough consensus". If the + committer has a conflict of interest in the discussion, for example due + to their position of employment, they are expected to put the needs of + the community project first. If they cannot put the community project + first, they must declare their conflict of interest, and allow other + non-conflicted committers to make any final decision. + </p> + + <p> + The committers are expected to monitor contributions to areas of the + project where they have expertize and ensure that either some form of + feedback is provided to the contributor, or to accept their contribution. + There is no formal minimum level of approval required to accept a + contribution. Positive review by any committer experienced in the area + of work is considered to be enough to justify acceptance in normal + circumstances. Where one committer explicitly rejects a contribution, + however, other committers should not override that rejection without + first establishing a "rough consensus" amongst the broader group of + committers. + </p> + + <p> + Being a committer is a privilege, not a right. In exceptional + circumstances, the privilege may be removed from an active + contributor. Such decisions will be taken based on "rough + consensus" amongst other committers. In the event that a committer + is no longer able to participate in the project, after some period + of inactivity passes, they may be asked to confirm that they wish + to retain their rights as a committer. + </p> + + <h3><a name="secteam">Security team</a></h3> + + <p> + The security team consists of a subset of the project committers + along with representatives from vendors shipping the project's + software. The subset of project committers is chosen to be the + minimal size neccessary to provide expertise spanning most of + the project's work. Further project committers may be requested + to engage in resolving specific security issues on a case by + case basis. Any vendor who is shipping the project's software + may submit a request for one or more of their representatives + to join the security team. Such requests must by approved by + existing members of the team vouching for the integrity of + the nominated person or organization. + </p> + + <p> + Members of the security team are responsible for triaging and + resolving any security issues that are reported to the project. + They are expected to abide by the project's documented + <a href="securityprocess.html">security process</a>. In particular + they must respect any embargo period agreed amongst the team + before disclosing a private issue. + </p> + + <h2><a name="roughconsensus">Rough consensus</a></h2> + + <p> + A core concept for governance of the project described above is + that of "rough consensus". To expand on this, it is a process + of decision making that involves the following steps + </p> + + <ul> + <li>Proposal</li> + <li>Discussion</li> + <li>Vote (exceptional circumstances only)</li> + <li>Decision</li> + </ul> + + <p> + To put this into words, any contributor is welcome to make a proposal + for consideration. Any contributor may participate in the discussions + around the proposal. The discussion will usually result in agreement + between the interested parties, or at least agreement between the + committers. Only in the very exceptional circumstance where there + is disagreement between committers, would a vote be considered. + Even in these exceptional circumstances, it is usually found to be + obvious what the majority opinion of the committers is. In the event + that even a formal vote is be tied, the committers will have to hold + ongoing discussions until the stalemate is resolved or the proposal + withdrawn. + </p> + + <p> + The overall goal of the "rough consensus" process is to ensure that + decisions can be made within the project, with a minimum level of + bureaucracy and process. Implicit in this is that any person who does + not explicitly reject to a proposal is assumed to be supportive, or + at least agnostic. + </p> + + + </body> +</html> -- 1.8.5.3

4 5