- Devel - libvirt List Archives

[libvirt] [PATCH v2 0/2] BSD: implement nodeGetCPUStats
by Roman Bogorodskiy 28 Jan '14

28 Jan '14

Updated patch which includes virsh update to not output unsupported CPU stat fields. For example, Linux output: user: 1.0% system: 1.0% idle: 98.0% iowait: 0.0% usage: 2.0% Includes iowait, doesn't have intr. FreeBSD output: user: 0,8% system: 0,9% idle: 97,5% intr: 0,8% usage: 2,5% Includes intr, doesn't have iowait. Roman Bogorodskiy (2): BSD: implement nodeGetCPUStats virsh: report only filled values in 'nodecpustats' include/libvirt/libvirt.h.in | 8 +++ src/nodeinfo.c | 104 +++++++++++++++++++++++++++++++++++++++ tools/virsh-host.c | 113 +++++++++++++++++++++++++++---------------- 3 files changed, 184 insertions(+), 41 deletions(-) -- 1.8.4.3

2 5

[libvirt] [PATCH 0/2] Try to get rid of most monitor timeout errors
by Martin Kletzander 28 Jan '14

28 Jan '14

This is basically v3 of the patch Pavel Fux sent [1] with the addition of changing the default as discussed in the same thread [2]. Martin [1] https://www.redhat.com/archives/libvir-list/2014-January/msg00060.html [2] https://www.redhat.com/archives/libvir-list/2014-January/msg00367.html Martin Kletzander (1): qemu: Change the default unix monitor timeout Pavel Fux (1): qemu: Add support for changing timeout value to open unix monitor socket src/qemu/libvirtd_qemu.aug | 3 +++ src/qemu/qemu.conf | 12 ++++++++++++ src/qemu/qemu_conf.c | 2 ++ src/qemu/qemu_conf.h | 2 ++ src/qemu/qemu_monitor.c | 20 +++++++++++++++++--- src/qemu/test_libvirtd_qemu.aug.in | 1 + 6 files changed, 37 insertions(+), 3 deletions(-) -- 1.8.5.2

4 17

[libvirt] [RFC PATCHv2 0/2] Implement tiered driver loading
by Adam Walters 28 Jan '14

28 Jan '14

This patchset implements a tiered driver loading system. I split the hypervisor drivers out into their own tier, which is loaded after the other drivers. This has the net effect of ensuring that things like secrets, networks, etc., are initialized and auto-started before any hypervisors, such as QEMU, LXC, etc. This resolves the race condition currently present when starting libvirtd while domains are running, which happens when restarting libvirtd after having started at least one domain. This patch will work without my config driver patchset, which is about to be submitted, as well. Without the config driver patchset, however, RBD storage pools using CephX authentication can not be auto-started due to a circular dependency between the QEMU and storage drivers. This may also affect other storage backends, but I currently only have the capacity to test with RBD and file backed storage pools. The reason this interferes with RBD storage pools is that currently, the storage driver has a hard-coded connection to QEMU in order to look up secrets. After this patchset, the QEMU driver will not be loaded until after the storage driver has completed its initialization and auto-start routines, which causes issues looking up secrets. Any pool type that does not use or need data from outside of the base storage pool definition should continue to auto-start along with no longer being affected by the current race condition. I have verified that file-based storage pools definitely auto-start fine after this patchset, and no longer have any issue with the current race condition. For anyone who is not familiar with the race condition I mention above, the basic description is that upon restarting libvirtd, any running QEMU domains using storage volumes are killed randomly due to their associated storage pool not yet being online. This is due to storage pool auto-start not having completed prior to QEMU initialization. In my prior testing, I found that this race condition affected at least one domain approximately 40% of the time. I sent this information to the mailing list back on 06DEC2013, if anyone is interested in going back and re-reading my description. I would appreciate any comments and suggestions about this patchset. It works for me on 4 machines running three different distros of Linux (Archlinux, Gentoo, and CentOS), so I would imagine that it should work most anywhere. Adam Walters (2): driver: Implement new state driver field libvirt: Implement tiered driver loading src/check-driverimpls.pl | 1 + src/driver.h | 7 +++++ src/interface/interface_backend_netcf.c | 1 + src/libvirt.c | 45 ++++++++++++++++++++------------- src/libxl/libxl_driver.c | 1 + src/lxc/lxc_driver.c | 1 + src/network/bridge_driver.c | 1 + src/node_device/node_device_hal.c | 1 + src/node_device/node_device_udev.c | 1 + src/nwfilter/nwfilter_driver.c | 1 + src/qemu/qemu_driver.c | 1 + src/remote/remote_driver.c | 1 + src/secret/secret_driver.c | 1 + src/storage/storage_driver.c | 1 + src/uml/uml_driver.c | 1 + src/xen/xen_driver.c | 1 + 16 files changed, 48 insertions(+), 18 deletions(-) -- 1.8.5.2

2 4

[libvirt] fix/re-do query-command-line-options
by Amos Kong 28 Jan '14

28 Jan '14

Hi QEMU/Libvirt list, When I worked on query-command-line-options, I first used some marcos [1] to generate two config & option tables. This will cover all the options, but it returns a string, it's difficult for libvirt to parse and use it. Finally I got a suggestion to read info from new interface (QemuOpts), We add opts info to vm_config_groups[], query-command-line-options will visit the array. It doesn't conver all the options, but the latest options are covered, so this implementation is acceptable. Problem: * QemuOpts was designed just for options with parameter, some new option without parameters is lost in query output (eg: -enable-fips) * block drive uses three QemuOpts, it's legacy issue. * QemuOpts of some options aren't updated, it might be difficult to updated when we add some new parameters * other We discussed to reimplement this command, but it seems DEF maroc is the only point to cover all the options, all the options are described in qemu-options.hx I'm considering to reuse the DEF marocs to generate a table, try to return the crude info if QemuOpts doesn't cover it. Or maintain a split array (like vm_config_groups[]), it only contains the option without parameter (option name & help info). If you touched some problem of the query-command-line-options, welcome to reply it, I will try to satisfy your requests. Thanks, Amos [1] http://www.redhat.com/archives/libvir-list/2013-January/msg01656.html |#elif defined(QEMU_OPTIONS_GENERATE_CONFIG) | |#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \ | opt_help, | |#define DEFHEADING(text) |#define ARCHHEADING(text, arch_mask) | |#elif defined(QEMU_OPTIONS_GENERATE_NAME) | |#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \ | option, | |#define DEFHEADING(text) |#define ARCHHEADING(text, arch_mask) char const *optionstr[] = { #define QEMU_OPTIONS_GENERATE_NAME #include "qemu-options-wrapper.h" }; char const *configstr[] = { #define QEMU_OPTIONS_GENERATE_CONFIG #include "qemu-options-wrapper.h" }; -- Amos.

4 10

[libvirt] [PATCHv3 0/4] Add a test for linuxNodeGetCPUStats
by Ján Tomko 28 Jan '14

28 Jan '14

v1: https://www.redhat.com/archives/libvir-list/2014-January/msg00951.html v2: https://www.redhat.com/archives/libvir-list/2014-January/msg00992.html use ticks instead of nsecs in test data v3: use nodeinfopriv.h instead of disgusting extern declarations touch up the impossible error message Ján Tomko (4): Move test-local declarations to nodeinfopriv.h Add test for linuxNodeGetCPUStats Simplify linuxNodeGetCPUStats Reword error message for oversized cpu time fields src/Makefile.am | 2 +- src/libvirt_linux.syms | 1 + src/nodeinfo.c | 87 ++++++---------- src/nodeinfopriv.h | 38 +++++++ tests/nodeinfodata/linux-cpustat-24cpu.out | 150 ++++++++++++++++++++++++++++ tests/nodeinfodata/linux-cpustat-24cpu.stat | 25 +++++ tests/nodeinfotest.c | 130 +++++++++++++++++++++++- 7 files changed, 373 insertions(+), 60 deletions(-) create mode 100644 src/nodeinfopriv.h create mode 100644 tests/nodeinfodata/linux-cpustat-24cpu.out create mode 100644 tests/nodeinfodata/linux-cpustat-24cpu.stat -- 1.8.3.2

3 13

Re: [libvirt] [PATCH 0/2] support compression with dumping guest memory
by Qiao Nuohan 28 Jan '14

28 Jan '14

Hello, Do you have some comments on this? On 01/21/2014 05:43 PM, qiaonuohan wrote: > --memory-only option is introduced without compression supported. Therefore, > this is a freature regression of virsh dump. This patchset is used to add > compression support in libvirt side and please refer the following address to > see the qemu side, the lastest version of qemu side v7(ready for comment now). > > http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg02139.html > > qiaonuohan (2): > support compression when --memory-only option is specified > support configuring the format of dumping memory in qemu.conf > > include/libvirt/libvirt.h.in | 18 +++++++++---- > src/libvirt.c | 15 +++++++++++ > src/qemu/libvirtd_qemu.aug | 1 + > src/qemu/qemu.conf | 6 +++++ > src/qemu/qemu_conf.c | 2 ++ > src/qemu/qemu_conf.h | 1 + > src/qemu/qemu_driver.c | 52 +++++++++++++++++++++++++++++++++++--- > src/qemu/qemu_monitor.c | 6 ++--- > src/qemu/qemu_monitor.h | 3 ++- > src/qemu/qemu_monitor_json.c | 4 ++- > src/qemu/qemu_monitor_json.h | 3 ++- > src/qemu/test_libvirtd_qemu.aug.in | 1 + > tests/qemumonitorjsontest.c | 2 +- > tools/virsh-domain.c | 29 +++++++++++++++++++++ > 14 files changed, 127 insertions(+), 16 deletions(-) > -- Regards Qiao Nuohan

3 2

[libvirt] [PATCH glib v2] Fix event loop implementation on win32
by Daniel P. Berrange 28 Jan '14

28 Jan '14

Libvirt uses gnulib for making winsock look like POSIX sockets. This means that in the libvirt event handle callbacks the application will be given a file descriptor rather than a winsock HANDLE object. The g_io_channel_unix_new method will detect that it is an FD and delegate to the g_io_channel_win32_new_fd method. Unfortunately the glib Win32 event loop impl is not very good at dealing with FD objects, simulating poll() by doing a read() on the FD :-( The API docs for g_io_channel_win32_new_fd say "All reads from the file descriptor should be done by this internal GLib thread. Your code should call only g_io_channel_read()." This isn't going to fly for libvirt, since it has zero knowledge of glib at all, so is just doing normal read(). Fortunately we can work around this problem by turning the FD we get from libvirt back into a HANDLE using the _get_osfhandle() method. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- libvirt-glib/libvirt-glib-event.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/libvirt-glib/libvirt-glib-event.c b/libvirt-glib/libvirt-glib-event.c index 87019b5..1e1ffec 100644 --- a/libvirt-glib/libvirt-glib-event.c +++ b/libvirt-glib/libvirt-glib-event.c @@ -31,6 +31,10 @@ #include "libvirt-glib/libvirt-glib.h" +#ifdef G_OS_WIN32 +#include <io.h> +#endif + /** * SECTION:libvirt-glib-event * @short_description: Integrate libvirt with the GMain event framework @@ -164,7 +168,11 @@ gvir_event_handle_add(int fd, data->events = events; data->cb = cb; data->opaque = opaque; +#ifdef G_OS_WIN32 + data->channel = g_io_channel_win32_new_socket(_get_osfhandle(fd)); +#else data->channel = g_io_channel_unix_new(fd); +#endif data->ff = ff; g_debug("Add handle %p %d %d %d %p\n", data, data->watch, data->fd, events, data->opaque); -- 1.8.4.2

2 1

[libvirt] [Question] About ivshmemory device and slot number confliction.
by Wangyufei (James) 28 Jan '14

28 Jan '14

Hello, I want to use ivshmemory device which is supported by qemu, but libvirt does not support it. So I use qemu:commandline to make ivshmemory device in qemu command pass-through. But then hot-plug a virtio-net device failed. The reason is that a qemu:commandline pci device's slot number is assigned by qemu not libvirt. And hot-plug device's slot is assigned by libvirt. So it failed beacause of slot confliction. I have two questions to ask: 1. Why libvirt does not support ivshmemory device? If libvirt intends to support it, when? 2. Can libvirt handle with qemu:commandline pci device's slot number? Just like pci:commandline to assign a slot number. what's your opinion? Best Regards, -WangYufei

3 2

[libvirt] [PATCH 0/5] Fix deadlock in nwfilter code
by Daniel P. Berrange 28 Jan '14

28 Jan '14

Since we introduced fine grained locking into the QEMU driver so that VM start can run in parallel, we appear to have caused a race with the nwfilter code. In particular since we no longer hold the global QEMU driver lock for the duration of VM startup we have a lock ordering flaw. This results in deadlock when nwfilter operations happen in parallel with VM startup. This also affects the LXC driver. This patch series attempts to address the problem https://bugzilla.redhat.com/show_bug.cgi?id=929412 the removal of the windows thread impl isn't strictly required, I just didn't want to waste time creating a read/write lock impl for Windows threads. Daniel P. Berrange (5): Add a read/write lock implementation Remove windows thread implementation in favour of pthreads Push nwfilter update locking up to top level Add a mutex to serialize updates to firewall Turn nwfilter conf update mutex into a read/write lock configure.ac | 15 +- src/Makefile.am | 4 - src/conf/nwfilter_conf.c | 23 +- src/conf/nwfilter_conf.h | 3 +- src/libvirt_private.syms | 8 +- src/lxc/lxc_driver.c | 6 + src/nwfilter/nwfilter_driver.c | 12 +- src/nwfilter/nwfilter_gentech_driver.c | 21 +- src/nwfilter/nwfilter_gentech_driver.h | 2 +- src/qemu/qemu_driver.c | 6 + src/uml/uml_driver.c | 4 + src/util/virthread.c | 291 +++++++++++++++++++++++- src/util/virthread.h | 51 ++++- src/util/virthreadpthread.c | 278 ----------------------- src/util/virthreadpthread.h | 49 ---- src/util/virthreadwin32.c | 396 --------------------------------- src/util/virthreadwin32.h | 53 ----- 17 files changed, 395 insertions(+), 827 deletions(-) delete mode 100644 src/util/virthreadpthread.c delete mode 100644 src/util/virthreadpthread.h delete mode 100644 src/util/virthreadwin32.c delete mode 100644 src/util/virthreadwin32.h -- 1.8.4.2

4 20

[libvirt] how nwfilter parse variable in xml file
by yue 28 Jan '14

28 Jan '14

hi,all we can define variable in nwfilter xml file, and assign value in domain xml . i add a new attribute , if the value is constant, it works . if it is variable, it will product wrong iptables rules. i want to know how libvirt process variable? where is the difference between processing constant and variable? when it is variable, if validator function is needed? thanks

1 0