[libvirt] [PATCH 0/6] Add group_name support for <iotune>
by John Ferlan
https://bugzilla.redhat.com/show_bug.cgi?id=1336564
Add support for "group" name in <iotune>.
The odd thing about the <iotune> group name is that support was added
in qemu after the _max parameters, but before the _max_length - so when
building the command line - that needs to be followed.
At least it's far less complicated than the _length parameters.
John Ferlan (6):
include: Add new "group_name" definition for iotune throttling
caps: Add new capability for the iotune group name
qemu: Add support for parsing iotune group setting
conf: Add support for blkiotune group_name option
qemu: Add the group name option to the iotune command line
virsh: Add group name to blkdeviotune output
docs/formatdomain.html.in | 11 ++++
docs/schemas/domaincommon.rng | 5 ++
include/libvirt/libvirt-domain.h | 15 +++++
src/conf/domain_conf.c | 10 +++
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 13 ++++
src/qemu/qemu_driver.c | 50 +++++++++++++--
src/qemu/qemu_monitor.c | 2 +
src/qemu/qemu_monitor.h | 1 +
src/qemu/qemu_monitor_json.c | 21 +++++-
src/qemu/qemu_monitor_json.h | 1 +
tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 +
.../caps_2.6.0-gicv2.aarch64.xml | 1 +
.../caps_2.6.0-gicv3.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 +
tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 +
tests/qemumonitorjsontest.c | 74 +++++++++++++++++-----
.../qemuxml2argv-blkdeviotune-group-num.args | 32 ++++++++++
.../qemuxml2argv-blkdeviotune-group-num.xml | 61 ++++++++++++++++++
tests/qemuxml2argvtest.c | 4 ++
.../qemuxml2xmlout-blkdeviotune-group-num.xml | 1 +
tests/qemuxml2xmltest.c | 1 +
tools/virsh-domain.c | 17 +++++
tools/virsh.pod | 5 +-
28 files changed, 309 insertions(+), 26 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune-group-num.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune-group-num.xml
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-blkdeviotune-group-num.xml
--
2.7.4
8 years, 1 month
[libvirt] [PATCH 00/17] Redo website layout and branding
by Daniel P. Berrange
The current libvirt website design dates from 2008 and
has not changed significantly since. Compared to
contemporary open source project websites it looks
pretty dated and cluttered.
This series incrementally changes the website to have
a completely new layout and branding.
Since the original adobe illustrator files are long
since lost, this series introduces a newly created
variant of the libvirt logo with Inkscape as an SVG
file.
The libvirt logo used a specific font with angled tops
to letters like "l", "b" and "t" - this is the "Overpass"
font, made available by Red Hat under an open source
font license. The re-branding makes use of webfont
support so that we can use this font across the entire
libvirt website for a consistent look.
The colors of the website CSS now exactly match the
colors used in the logo in most places.
The bigger change is in the layout, with the huge
left hand sitemap nav bar being removed to give more
space to the main content. The front page now directly
links to the key pages that were shown to be highly
visited in the apache web logs. Most of the rest of
the links are now available from the "docs.html" page
linked from "Learn" in the top nav bar.
Another key change is that the download page now
covers all language bindings, test suites, docs
released by the project, not merely the core C
library.
Finally a new page "contribute.html" is added as the
source of information useful to people wishing to get
involved in the libvirt project.
View the new site here
https://berrange.fedorapeople.org/libvirt-new-website/
Note that the front page includes a feed of 4 most
recent blog posts, however, if visiting over https://
this will be blocked by browsers. In firefox you
can tell it to allow http:// content temporarily
at which point the feed will appear. I'll be doing
a proper fix by getting a TLS cert for virt-tools.org
website setup.
Daniel P. Berrange (17):
docs: use overpass font for website
docs: switch to new website banner
docs: redo style of front page
docs: add footer to all pages
docs: simplify style for headers
docs: add page describing contribution to libvirt
docs: add three core links in the header bar
docs: remove todo page
docs: remove related links page
Revert "syntax-check: Enforce <code> inside <dt> elements"
docs: rewrite content on front page to be more useful
docs: expand downloads page to cover all modules
docs: add some improved styling to contact page
docs: fill out docs page with useful links
docs: remove navigation sidebar from pages
docs: remove outdated or duplicated content
docs: add master SVG for libvirt logo
cfg.mk | 20 +-
docs/404.html.in | 5 -
docs/Makefile.am | 50 +-
docs/archdomain.html.in | 7 -
docs/archnetwork.html.in | 54 -
docs/archnode.html.in | 7 -
docs/archstorage.html.in | 32 -
docs/contact.html.in | 4 +-
docs/contribute.html.in | 140 ++
docs/deployment.html.in | 50 -
docs/docs.html.in | 161 +-
docs/downloads.html.in | 391 ++++-
docs/fonts/LICENSE.md | 90 ++
docs/fonts/hinted-Overpass-Bold.woff | Bin 0 -> 48136 bytes
docs/fonts/hinted-Overpass-BoldItalic.woff | Bin 0 -> 51008 bytes
docs/fonts/hinted-Overpass-Italic.woff | Bin 0 -> 51908 bytes
docs/fonts/hinted-Overpass-Light.woff | Bin 0 -> 49452 bytes
docs/fonts/hinted-Overpass-LightItalic.woff | Bin 0 -> 51752 bytes
docs/fonts/hinted-Overpass-Reg.woff | Bin 0 -> 48144 bytes
docs/fonts/stylesheet.css | 55 +
docs/formatsnapshot.html.in | 6 +-
docs/generic.css | 11 +-
docs/hvsupport.pl | 3 -
docs/index.html.in | 162 +-
docs/intro.html.in | 13 -
docs/js/jquery-3.1.1.min.js | 4 +
docs/js/jquery.rss.min.js | 11 +
docs/js/moment.min.js | 7 +
docs/libvirt-header-bg.png | Bin 1136 -> 0 bytes
docs/libvirt-header-logo.png | Bin 25945 -> 0 bytes
docs/libvirt-net-logical.fig | 159 --
docs/libvirt-net-logical.png | Bin 11243 -> 0 bytes
docs/libvirt-net-physical.fig | 139 --
docs/libvirt-net-physical.png | Bin 11336 -> 0 bytes
docs/libvirt.css | 319 ++--
docs/libvirtLogo.png | Bin 33698 -> 0 bytes
docs/libvirtLogo404.png | Bin 32442 -> 0 bytes
docs/logo-large-banner.png | Bin 0 -> 86032 bytes
docs/logo-small-banner-light.png | Bin 0 -> 19049 bytes
docs/logo.svg | 2153 +++++++++++++++++++++++++++
docs/main.css | 1 +
docs/page.xsl | 101 +-
docs/pending.html.in | 10 -
docs/relatedlinks.html.in | 88 --
docs/remote.html.in | 2 +-
docs/search.php.in | 2 -
docs/sitemap.html.in | 490 ------
docs/todo.cfg-example | 26 -
docs/todo.pl | 125 --
49 files changed, 3263 insertions(+), 1635 deletions(-)
delete mode 100644 docs/archdomain.html.in
delete mode 100644 docs/archnetwork.html.in
delete mode 100644 docs/archnode.html.in
delete mode 100644 docs/archstorage.html.in
create mode 100644 docs/contribute.html.in
delete mode 100644 docs/deployment.html.in
create mode 100644 docs/fonts/LICENSE.md
create mode 100644 docs/fonts/hinted-Overpass-Bold.woff
create mode 100644 docs/fonts/hinted-Overpass-BoldItalic.woff
create mode 100644 docs/fonts/hinted-Overpass-Italic.woff
create mode 100644 docs/fonts/hinted-Overpass-Light.woff
create mode 100644 docs/fonts/hinted-Overpass-LightItalic.woff
create mode 100644 docs/fonts/hinted-Overpass-Reg.woff
create mode 100644 docs/fonts/stylesheet.css
delete mode 100644 docs/intro.html.in
create mode 100644 docs/js/jquery-3.1.1.min.js
create mode 100644 docs/js/jquery.rss.min.js
create mode 100644 docs/js/moment.min.js
delete mode 100644 docs/libvirt-header-bg.png
delete mode 100644 docs/libvirt-header-logo.png
delete mode 100644 docs/libvirt-net-logical.fig
delete mode 100644 docs/libvirt-net-logical.png
delete mode 100644 docs/libvirt-net-physical.fig
delete mode 100644 docs/libvirt-net-physical.png
delete mode 100644 docs/libvirtLogo.png
delete mode 100644 docs/libvirtLogo404.png
create mode 100644 docs/logo-large-banner.png
create mode 100644 docs/logo-small-banner-light.png
create mode 100644 docs/logo.svg
delete mode 100644 docs/pending.html.in
delete mode 100644 docs/relatedlinks.html.in
delete mode 100644 docs/sitemap.html.in
delete mode 100644 docs/todo.cfg-example
delete mode 100755 docs/todo.pl
--
2.9.3
8 years, 1 month
[libvirt] [PATCH v2 0/3] wireshark: Further build system fixes
by Andrea Bolognani
Changes from v1:
* don't attempt to strip the wireshark prefix when we're
building the plugindir ourselves
* use exec_prefix instead of prefix everywhere (suggested
by Viktor Mihajlovski)
Andrea Bolognani (3):
wireshark: Don't redefine ws_plugindir
wireshark: Make fallback path construction more reliable
wireshark: Use ${exec_prefix} instead of ${prefix}
m4/virt-wireshark.m4 | 25 +++++++++++++------------
tools/Makefile.am | 1 -
2 files changed, 13 insertions(+), 13 deletions(-)
--
2.7.4
8 years, 1 month
[libvirt] [PATCH RFC] virhook: Adding inotify support to virhook.
by Julio Faracco
Libvirtd only support hooks when the daemon is started. Hooks cannot be
loaded when the daemon is already running. So, to load a hook you need to
restart the service everytime. Now, the inotify support enables the option
of create a hook and run it even if libvirtd was started.
Cc: Carlos Castilho <ccasti(a)br.ibm.com>
Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com>
---
daemon/libvirtd.c | 1 +
src/libvirt_private.syms | 1 +
src/util/virhook.c | 165 ++++++++++++++++++++++++++++++++++++++++++++++-
src/util/virhook.h | 10 +++
4 files changed, 175 insertions(+), 2 deletions(-)
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index 95c1b1c..56175d1 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -1622,6 +1622,7 @@ int main(int argc, char **argv) {
0, "shutdown", NULL, NULL);
cleanup:
+ virHookCleanUp();
virNetlinkEventServiceStopAll();
virObjectUnref(remoteProgram);
virObjectUnref(lxcProgram);
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 6a77e46..c8ad816 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -1648,6 +1648,7 @@ virHashValueFree;
virHookCall;
virHookInitialize;
virHookPresent;
+virHookCleanUp;
# util/virhostdev.h
diff --git a/src/util/virhook.c b/src/util/virhook.c
index facd74a..d5fc928 100644
--- a/src/util/virhook.c
+++ b/src/util/virhook.c
@@ -26,6 +26,7 @@
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/stat.h>
+#include <sys/inotify.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
@@ -45,6 +46,10 @@ VIR_LOG_INIT("util.hook");
#define LIBVIRT_HOOK_DIR SYSCONFDIR "/libvirt/hooks"
+#define virHookInstall(driver) virHooksFound |= (1 << driver);
+
+#define virHookUninstall(driver) virHooksFound ^= (1 << driver);
+
VIR_ENUM_DECL(virHookDriver)
VIR_ENUM_DECL(virHookDaemonOp)
VIR_ENUM_DECL(virHookSubop)
@@ -109,6 +114,8 @@ VIR_ENUM_IMPL(virHookLibxlOp, VIR_HOOK_LIBXL_OP_LAST,
static int virHooksFound = -1;
+static virHookInotifyPtr virHooksInotify = NULL;
+
/**
* virHookCheck:
* @driver: the driver name "daemon", "qemu", "lxc"...
@@ -153,6 +160,121 @@ virHookCheck(int no, const char *driver)
return ret;
}
+/**
+ * virHookInotifyEvent:
+ * @fd: inotify file descriptor.
+ *
+ * Identifies file events at libvirt's hook directory.
+ * Install or uninstall hooks on demand. Acording file manipulation.
+ */
+static void
+virHookInotifyEvent(int watch ATTRIBUTE_UNUSED,
+ int fd,
+ int events ATTRIBUTE_UNUSED,
+ void *data ATTRIBUTE_UNUSED)
+{
+ char buf[1024];
+ struct inotify_event *e;
+ int got;
+ int driver;
+ char *tmp, *name;
+
+ VIR_DEBUG("inotify event in virHookInotify()");
+
+reread:
+ got = read(fd, buf, sizeof(buf));
+ if (got == -1) {
+ if (errno == EINTR)
+ goto reread;
+ return;
+ }
+
+ tmp = buf;
+ while (got) {
+ if (got < sizeof(struct inotify_event))
+ return;
+
+ VIR_WARNINGS_NO_CAST_ALIGN
+ e = (struct inotify_event *)tmp;
+ VIR_WARNINGS_RESET
+
+ tmp += sizeof(struct inotify_event);
+ got -= sizeof(struct inotify_event);
+
+ if (got < e->len)
+ return;
+
+ tmp += e->len;
+ got -= e->len;
+
+ name = (char *)&(e->name);
+
+ /* Removing hook file. */
+ if (e->mask & (IN_DELETE | IN_MOVED_FROM)) {
+ if ((driver = virHookDriverTypeFromString(name)) < 0) {
+ VIR_DEBUG("Invalid hook name for %s", name);
+ return;
+ }
+
+ virHookUninstall(driver);
+ }
+
+ /* Creating hook file. */
+ if (e->mask & (IN_CREATE | IN_CLOSE_WRITE | IN_MOVED_TO)) {
+ if ((driver = virHookDriverTypeFromString(name)) < 0) {
+ VIR_DEBUG("Invalid hook name for %s", name);
+ return;
+ }
+
+ virHookInstall(driver);
+ }
+ }
+}
+
+/**
+ * virHookInotifyInit:
+ *
+ * Initialize inotify hooks support.
+ * Enable hooks installation on demand.
+ *
+ * Returns 0 if inotify was successfully installed, -1 in case of failure.
+ */
+static int
+virHookInotifyInit(void) {
+
+ if (VIR_ALLOC(virHooksInotify) < 0)
+ goto error;
+
+ if ((virHooksInotify->inotifyFD = inotify_init()) < 0) {
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("cannot initialize inotify"));
+ goto error;
+ }
+
+ if ((virHooksInotify->inotifyWatch =
+ inotify_add_watch(virHooksInotify->inotifyFD,
+ LIBVIRT_HOOK_DIR,
+ IN_CREATE | IN_MODIFY | IN_DELETE)) < 0) {
+ virReportSystemError(errno, _("Failed to create inotify watch on %s"),
+ LIBVIRT_HOOK_DIR);
+ goto error;
+ }
+
+ if ((virHooksInotify->inotifyHandler =
+ virEventAddHandle(virHooksInotify->inotifyFD,
+ VIR_EVENT_HANDLE_READABLE,
+ virHookInotifyEvent, NULL, NULL)) < 0) {
+ VIR_DEBUG("Failed to add inotify handle in virHook.");
+ goto error;
+ }
+
+ return 0;
+
+error:
+ virHookCleanUp();
+ return -1;
+}
+
+
/*
* virHookInitialize:
*
@@ -174,10 +296,14 @@ virHookInitialize(void)
return -1;
if (res == 1) {
- virHooksFound |= (1 << i);
+ virHookInstall(i);
ret++;
}
}
+
+ if (virHookInotifyInit() < 0)
+ VIR_INFO("Disabling hooks inotify support.");
+
return ret;
}
@@ -309,7 +435,12 @@ virHookCall(int driver,
if (output)
virCommandSetOutputBuffer(cmd, output);
- ret = virCommandRun(cmd, NULL);
+ ret = virHookCheck(driver, virHookDriverTypeToString(driver));
+
+ if (ret > 0) {
+ ret = virCommandRun(cmd, NULL);
+ }
+
if (ret < 0) {
/* Convert INTERNAL_ERROR into known error. */
virReportError(VIR_ERR_HOOK_SCRIPT_FAILED, "%s",
@@ -322,3 +453,33 @@ virHookCall(int driver,
return ret;
}
+
+/**
+ * virHookCall:
+ *
+ * Release all structures and data used in virhooks.
+ *
+ * Returns: 0 if the execution succeeded
+ */
+int
+virHookCleanUp(void)
+{
+ if (!virHooksInotify)
+ return -1;
+
+ if ((virHooksInotify->inotifyFD >= 0) &&
+ (virHooksInotify->inotifyWatch >= 0))
+ if (inotify_rm_watch(virHooksInotify->inotifyFD,
+ virHooksInotify->inotifyWatch) < 0)
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Cannot remove inotify watcher."));
+
+ if (virHooksInotify->inotifyHandler >= 0)
+ virEventRemoveHandle(virHooksInotify->inotifyHandler);
+
+ VIR_FORCE_CLOSE(virHooksInotify->inotifyFD);
+ VIR_FREE(virHooksInotify);
+
+ virHooksFound = -1;
+
+ return 0;
+}
diff --git a/src/util/virhook.h b/src/util/virhook.h
index 205249c..47a32c7 100644
--- a/src/util/virhook.h
+++ b/src/util/virhook.h
@@ -100,6 +100,14 @@ typedef enum {
VIR_HOOK_LIBXL_OP_LAST,
} virHookLibxlOpType;
+struct _virHookInotify {
+ int inotifyFD;
+ int inotifyWatch;
+ int inotifyHandler;
+};
+
+typedef struct _virHookInotify *virHookInotifyPtr;
+
int virHookInitialize(void);
int virHookPresent(int driver);
@@ -107,4 +115,6 @@ int virHookPresent(int driver);
int virHookCall(int driver, const char *id, int op, int sub_op,
const char *extra, const char *input, char **output);
+int virHookCleanUp(void);
+
#endif /* __VIR_HOOKS_H__ */
--
2.7.4
8 years, 1 month
[libvirt] pci-assign fails with read error on config-space file
by Henning Schild
Hey,
i am running an unusual setup where i assign pci devices behind the
back of libvirt. I have two options to do that:
1. a wrapper script for qemu that takes care of suid-root and appends
arguments for pci-assign
2. virsh qemu-monitor-command ... 'device_add pci-assign...'
I know i should probably not be doing this, it is a workaround to
introduce fine-grained pci-assignment in an openstack setup, where
vendor and device id are not enough to pick the right device for a vm.
In both cases qemu will crash with the following output:
> qemu: hardware error: pci read failed, ret = 0 errno = 22
followed by the usual machine state dump. With strace i found it to be
a failing read on the config space file of my device.
/sys/bus/pci/devices/0000:xx:xx.x/config
A few reads out of that file succeeded, as well as accesses on vendor
etc.
Manually launching a qemu with the pci-assign works without a problem,
so i "blame" libvirt and the cgroup environment the qemu ends up in.
So i put a bash into the exact same cgroup setup - next to a running
qemu, expecting a dd or hexdump on the config-space file to fail. But
from that bash i can read the file without a problem.
Has anyone seen that problem before? Right now i do not know what i
am missing, maybe qemu is hitting some limits configured for the
cgroups or whatever. I can not use pci-assign from libvirt, but if i
did would it configure cgroups in a different way or relax some limits?
What would be a good next step to debug that? Right now i am looking at
kernel event traces, but the machine is pretty big and so is the trace.
That assignment used to work and i do not know how it broke, i have
tried combinations of several kernels, versions of libvirt and qemu.
(kernel 3.18 and 4.4, libvirt 1.3.2 and 2.0.0, and qemu 2.2.1 and 2.7)
All combinations show the same problem, even the ones that work on
other machines. So when it comes to software versions the problem could
well be caused by a software update of another component, that i
got with the package manager and did not compile myself. It is a debian
8.6 with all recent updates installed. My guess would be that systemd
could have an influence on cgroups or limits causing such a problem.
regards,
Henning
8 years, 1 month
[libvirt] [PATCH v3 0/6] New libssh transport
by Pino Toscano
Hi,
this series introduces a new libssh transport in libvirt, based on the
libssh C library. This library supports what libssh2 does, and more:
- easier API for known_hosts handling (there's a ticket upstream to
request extensions for it, but what is implemented now works well)
- potential GSSAPI authentication (not enabled yet because of a libssh
bug [1])
- easier API for ssh-agent support
The implementation for the new transport is based on the libssh2 one,
hence it shares origin and style.
[1] https://red.libssh.org/issues/242
Thanks,
Changes from v2 to v3:
- split into more commits
- integrate all the issues spotted by Daniel P. Berrange and
Peter Krempa
- restore the specified order of authentication methods (as in libssh2)
- add a related documentation fix
- minor coding fixes
Changes from v1 to v2:
- implemented keyboard interactive
- code polish, and fixes
Pino Toscano (6):
virNetSocket: allow to not close FD
virerror: add error for libssh transport
libssh_transport: add new libssh-based transport
remote: expose a new libssh transport
spec: enable libssh transport on Fedora
docs: fix default value for sshauth option of libssh2/libssh
config-post.h | 2 +
configure.ac | 3 +
docs/remote.html.in | 39 +-
include/libvirt/virterror.h | 2 +
libvirt.spec.in | 10 +
m4/virt-libssh.m4 | 26 +
po/POTFILES.in | 1 +
src/Makefile.am | 21 +-
src/libvirt_libssh.syms | 22 +
src/remote/remote_driver.c | 41 ++
src/rpc/virnetclient.c | 118 ++++
src/rpc/virnetclient.h | 13 +
src/rpc/virnetlibsshsession.c | 1458 +++++++++++++++++++++++++++++++++++++++++
src/rpc/virnetlibsshsession.h | 80 +++
src/rpc/virnetsocket.c | 184 +++++-
src/rpc/virnetsocket.h | 13 +
src/util/virerror.c | 9 +-
17 files changed, 2024 insertions(+), 18 deletions(-)
create mode 100644 m4/virt-libssh.m4
create mode 100644 src/libvirt_libssh.syms
create mode 100644 src/rpc/virnetlibsshsession.c
create mode 100644 src/rpc/virnetlibsshsession.h
--
2.7.4
8 years, 1 month
[libvirt] [PATCH v2] qemu: report block job errors from qemu to the user
by Nikolay Shirokovskiy
So that you can see nice report on migration:
"error: operation failed: migration of disk sda failed: No space left on device"
diff from v1:
1. drop 1 patch. Avoiding default label in switches is desired style.
2. drop 2 patch. I do not investigate enough to touch that place.
3. fix 3 patch
a) as suggested by Jiri
* fix leaks
* s/hint/error/g
* don't show <NULL> in error message
* take suggested code simplifications
b) extra
* print error string from qemu to log in case we have to drop it
Nikolay Shirokovskiy (1):
qemu: report block job errors from qemu to the user
src/qemu/qemu_blockjob.c | 13 +++++++++--
src/qemu/qemu_blockjob.h | 3 ++-
src/qemu/qemu_domain.c | 1 +
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_driver.c | 4 ++--
src/qemu/qemu_migration.c | 54 +++++++++++++++++++++++++++++++-------------
src/qemu/qemu_monitor.c | 5 ++--
src/qemu/qemu_monitor.h | 4 +++-
src/qemu/qemu_monitor_json.c | 4 +++-
src/qemu/qemu_process.c | 4 ++++
10 files changed, 68 insertions(+), 25 deletions(-)
--
1.8.3.1
8 years, 1 month
[libvirt] [PATCH] docs: remove obsolete library.xen file
by Daniel P. Berrange
The library.xen file contains a braindump of thoughts dating
from the very first days of libvirt, when it was briefly
called libxen. This is not useful and potentially misleading
or confusing for people.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
cfg.mk | 2 +-
docs/library.xen | 100 -------------------------------------------------------
2 files changed, 1 insertion(+), 101 deletions(-)
delete mode 100644 docs/library.xen
diff --git a/cfg.mk b/cfg.mk
index 9546853..a4305a8 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -1220,7 +1220,7 @@ exclude_file_name_regexp--sc_prohibit_mixed_case_abbreviations = \
^src/(vbox/vbox_CAPI.*.h|esx/esx_vi.(c|h)|esx/esx_storage_backend_iscsi.c)$$
exclude_file_name_regexp--sc_prohibit_empty_first_line = \
- ^(README|daemon/THREADS\.txt|src/esx/README|docs/library.xen|tests/(vmwarever|virhostcpu)data/.*)$$
+ ^(README|daemon/THREADS\.txt|src/esx/README|tests/(vmwarever|virhostcpu)data/.*)$$
exclude_file_name_regexp--sc_prohibit_useless_translation = \
^tests/virpolkittest.c
diff --git a/docs/library.xen b/docs/library.xen
deleted file mode 100644
index 2e1b2c5..0000000
--- a/docs/library.xen
+++ /dev/null
@@ -1,100 +0,0 @@
-
- About a libxen library
- ======================
-
-Functional description:
------------------------
-
- Small C library to be able to control Xen Linux guest, i.e.
- provide the following operations for Xen guest domains running Linux
- from domain 0 code linked to the library (running as root):
- - start
- - stop
- - suspend
- - resume
- - monitor
- More advanced features should be allowed as future extensions, but
- are not expected to be provided in first shipment.
-
- Open enough Licence that customers can link their apps to it (LGPL)
-
- Small and contained enough that we can use it as a way to
- provide API and ABI stability in spite if the evolution of Xen
- existing API and hypervisor calls.
-
-The current state of Xen userland:
-----------------------------------
-
- the existing Xen 3.0 userland code is mostly based on tiny C functions
-using direct hypervisor calls (or /proc/xen/ interfaces) and a lot of
-Python code on top driving the hypervisor.
- The C code is relatively hairy, functions with 10 parameters or more
-are not uncommon, and it is very low level usually without comment about
-the function or its arguments. They are usually only called once in the
-whole tree by the python bindings. In essence it looks like the Xen project
-was not implemented with the idea of reusing that part of the code by
-applications.
- Indeed most of the userland code coming with Xen is built on Python,
-like xend the xen daemon running on domain 0 or the xenstored daemon which
-manage the state of the domains launched.
-
-Rebuilding a library ?:
------------------------
-
- Providing a library at the C level to drive domain execution is in a
-very large part a rimplementation of existing code but in a different way
-and somehow with different goals for the code. The existing Licence (GPL)
-makes it uneasy, we can't copy GPL code to put it in a LGPL'ed library,
-and rewriting everything while looking at the Xen code will inevitably
-lead to code similarities especially with this kind of system code. Plus
-we will still need to run xend and probably xenstored to not diverge
-completely from Xen existing code base.
-
-The IBM way:
-------------
-
- Here is supposition about code that I can't instanciate except by looking
-at said code but it looks that IBM also needed a C programmatic API to
-manage the Xen domain definitions. Their solution was to build (Rusty
-Russell did this) an LGPL C API connecting directly to the xenstore
-daemon (./tools/xenstore/*). In a way this is quite more fragile as it depends
-on the whole existing stack of the Xen code, but it isolate the API
-from the implementation details of the current Xen source (API in
-./tools/xenstore/xs.h). The goal seems to be more about testing and controlling
-the xen store daemon, but it shows a different approach to decouple client
-API/ABI from the Xen existing code.
-
-Open question:
----------------
-
- To what extent should libxen be a rewrite or an isolation layer around
-some of the existing code ?
-
- Rewrite:
-
- Pros:
- - avoid the GPL Licence problem potentially more users
- - allow do build a cleaner more stable layer
- - the existing code is frightening
- Cons:
- - awful lot of work debugging very hard
- - will still require existing Xen code to be running
- - splitting interfaces is hard politically and lower the
- Open Source efforts toward the project
-
- Wrappers on top of existing code:
-
- Pros:
- - much smaller code rewrite
- - benefits from the bugfixes injected by other patchers upstream
- Cons:
- - Licence constraint GPL only for apps
- - API/ABI isolation may not be easier in that way
-
- Potentially the API could be implemented as a layer on top of the existing
-libxc C code library and then progressively migrating out the existing
-dependence to Xen code as the interfaces stabilize.
-
-Daniel Veillard <veillard(a)redhat.com>
-
-Mon Oct 24 18:40:19 CEST 2005
--
2.9.3
8 years, 1 month
[libvirt] [PATCH v2 python 0/2] fix crash in libvirt_virDomainPin*
by Konstantin Neumoin
this small patch set:
* move common logic of all libvirt_virDomainPin* functions to new helper
in util module.
* add check for pycpumap length.
Changes since v1:
- add new helper in util module.
Konstantin Neumoin (2):
minor clean-up for libvirt_virDomainPin*
add check for pycpumap length
libvirt-override.c | 131 +++++------------------------------------------------
libvirt-utils.c | 63 ++++++++++++++++++++++++++
libvirt-utils.h | 5 ++
3 files changed, 79 insertions(+), 120 deletions(-)
--
2.5.5
8 years, 1 month
[libvirt] VLAN-based direct interface
by Ed Swierk
In my setup, the network interfaces of several KVM-based VMs all
communicate with the outside world via a single host interface, which
is in turn connected to an external switch that handles all network
policy to/from/between VMs. Traffic between the host and the switch is
segregated by VLAN ID, one per vNIC.
When I spin up a new VM with one vNIC assigned (say) VLAN ID 101, I
run ip link add link eth0 name eth0.101 type vlan id 101. In the
libvirt config I write
<interface type='direct' trustGuestRxFilters='yes'>
<source dev='eth0.101' mode='passthrough'/>
<model type='virtio'/>
</interface>
This causes libvirt to create a macvtap interface attached to eth0.101
in passthrough mode.
So far, so good. The guest OS thinks it has a plain old NIC on an
untagged switch port. When the guest OS joins an IPv6 link-local
solicited-node multicast group, QEMU tells libvirt to add the
corresponding multicast MAC address to the macvtap interface. I can
even run a trunk port all the way through to the VM, with traffic
double-tagged through the switch-host hop.
Trouble arises if I change the model from virtio to e1000, to support
an application that doesn't (yet) have virtio drivers. QEMU doesn't
expose state via query-rx-filter for e1000 interfaces, so libvirt
can't sync multicast MAC addresses from the guest to the macvtap
interface, so the guest can't talk IPv6.
Ideally QEMU would support query-rx-filter for e1000 and other NIC
models. But for my application all the careful syncing of guest rx
filter state is overkill: I need the macvtap interface to pass all
traffic between the guest and host with no filtering at all. I can
achieve this simply by enabling promiscuous mode on the macvtap
interface. But libvirt creates the interface, and I don't see any way
to get libvirt to enable promiscuous mode and leave it enabled.
It wouldn't be hard to add another configuration flag that tells
libvirt to just put the macvtap interface into promiscuous mode and
skip syncing guest rx filters. Perhaps add another value for
trustGuestRxFilters, like 'promisc'?
However just solving that minor problem seems like piling one hack on
top of another: taking a normal interface and attaching a VLAN
interface to it, then attaching a macvtap interface to that, and
beating the mac out of the macvtap until it behaves like a dumb bridge
(or, attaching a bridge to the VLAN interface, creating a tap
interface, and enslaving the tap to the bridge, old-school).
What I'm really after is just another kind of direct interface that
attaches to a host interface, but instead of directing traffic to the
guest by MAC address it uses the VLAN ID (and also adds/strips the
tag). libvirt could implement this by automating all the steps I just
described. Or if the kernel ever sprouts the VLAN equivalent of the
macvtap driver (vlanvtap?), libvirt could just use that.
Any opinions on first-class support for a VLAN-based direct interface,
versus just allowing configuration of promiscuous mode on a macvtap
direct interface?
--Ed
8 years, 1 month
