October 2016 - Devel - libvirt List Archives

[libvirt] FOSDEM 2017: Call For Proposals -- Virtualization & IaaS DevRoom
by Kashyap Chamarthy 11 Nov '16

11 Nov '16

======================================================================= The call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2017, to be hosted on February 4, 2017. This year will mark FOSDEM’s 17th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. FOSDEM will be held once again in Brussels, Belgium, on February 4 & 5, 2017. --------------- Important Dates --------------- Submission deadline: 18 November 2016 Acceptance notifications: 04 December 2016 Final schedule announcement: 11 December 2016 Devroom: 04 February 2017 (one day) ----------------- About the Devroom ----------------- The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, QEMU, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as Apache CloudStack, OpenStack, oVirt, OpenNebula, and Ganeti. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. -------------------- Submit Your Proposal -------------------- All submissions must be made via the Pentabarf event planning site. https://penta.fosdem.org/submission/FOSDEM17 If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualisation and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. --------------------- Submission Guidelines --------------------- - We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. - All presentation slots are 45 minutes, with 35 minutes planned for presentations, and 10 minutes for Q&A. - All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." - In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) ------------------- Call for Volunteers ------------------- We are also looking for volunteers to help run the devroom. We need assistance watching time for the speakers, and helping with video for the devroom. Please contact Brian Proffitt (bkp at redhat.com) for more information. ---------- Questions? ---------- If you have any questions about this devroom, please send your questions to our devroom mailing list. iaas-virt-devroom(a)lists.fosdem.org You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. ======================================================================= -- /kashyap

1 1

[libvirt] [PATCH 0/6] Add group_name support for <iotune>
by John Ferlan 07 Nov '16

07 Nov '16

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

3 16

[libvirt] [PATCH 00/17] Redo website layout and branding
by Daniel P. Berrange 07 Nov '16

07 Nov '16

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 43

[libvirt] [PATCH v2 0/3] wireshark: Further build system fixes
by Andrea Bolognani 07 Nov '16

07 Nov '16

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

2 5

[libvirt] [PATCH RFC] virhook: Adding inotify support to virhook.
by Julio Faracco 03 Nov '16

03 Nov '16

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

2 4

[libvirt] pci-assign fails with read error on config-space file
by Henning Schild 02 Nov '16

02 Nov '16

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

5 7

[libvirt] [PATCH v3 0/6] New libssh transport
by Pino Toscano 02 Nov '16

02 Nov '16

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

2 12

[libvirt] [PATCH v2] qemu: report block job errors from qemu to the user
by Nikolay Shirokovskiy 02 Nov '16

02 Nov '16

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

2 4

[libvirt] [PATCH] docs: remove obsolete library.xen file
by Daniel P. Berrange 01 Nov '16

01 Nov '16

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

2 2

[libvirt] [PATCH v2 python 0/2] fix crash in libvirt_virDomainPin*
by Konstantin Neumoin 01 Nov '16

01 Nov '16

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

2 5