- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: fix domjobabort regression
by Eric Blake 11 Nov '11

11 Nov '11

This reverts commit ef1065cf5ac; see also this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=751900 In qemu 0.15.1 and earlier, during migration to file, the qemu_savevm_state_begin and qemu_savevm_state_iterate methods will both process as much migration data as possible until either 1. The file descriptor returns EAGAIN 2. The bandwidth rate limit is reached If we set the rate limit to ULONG_MAX, test 2 never becomes true. We're passing a plain file descriptor to QEMU and POSIX does not support EAGAIN on regular files / block devices, so test 1 never becomes true either. In the 'virsh save --bypass-cache' case, we pass a pipe instead of a regular fd, but using a pipe adds I/O overhead, so always passing a pipe just so qemu can see EAGAIN doesn't seem nice. The ultimate fix needs to come from qemu - background migration must respect asynchronous abort requests, or else periodically return control to the main handling loop without an EAGAIN and without waiting to hit an insanely large amount of data. But until a version of qemu is fixed to support "unlimited" data rates while still allowing cancellation, the best we can do is avoid the automatic use of unlimited rates from within libvirt (users can still explicitly change the migration rates, if they are aware that they are giving up the ability to cancel a job). Reverting the lone use of QEMU_DOMAIN_FILE_MIG_BANDWIDTH_MAX is the simplest patch; this slows migration back down to a default 32M/sec cap, but also ensures that the main qemu processing loop will still be responsive to cancellation requests. Hopefully upstream qemu will provide us a means of safely using unlimited speed, including a runtime probe of that capability. * src/qemu/qemu_migration.c (qemuMigrationToFile): Revert attempt to use unlimited migration bandwidth when migrating to file. Signed-off-by: Daniel Veillard <veillard(a)redhat.com> Signed-off-by: Eric Blake <eblake(a)redhat.com> --- src/qemu/qemu_migration.c | 17 ----------------- 1 files changed, 0 insertions(+), 17 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 838a31f..30f805d 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2825,16 +2825,6 @@ qemuMigrationToFile(struct qemud_driver *driver, virDomainObjPtr vm, bool restoreLabel = false; virCommandPtr cmd = NULL; int pipeFD[2] = { -1, -1 }; - unsigned long saveMigBandwidth = priv->migMaxBandwidth; - - /* Increase migration bandwidth to unlimited since target is a file. - * Failure to change migration speed is not fatal. */ - if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) == 0) { - qemuMonitorSetMigrationSpeed(priv->mon, - QEMU_DOMAIN_FILE_MIG_BANDWIDTH_MAX); - priv->migMaxBandwidth = QEMU_DOMAIN_FILE_MIG_BANDWIDTH_MAX; - qemuDomainObjExitMonitorWithDriver(driver, vm); - } if (qemuCapsGet(priv->qemuCaps, QEMU_CAPS_MIGRATE_QEMU_FD) && (!compressor || pipe(pipeFD) == 0)) { @@ -2946,13 +2936,6 @@ qemuMigrationToFile(struct qemud_driver *driver, virDomainObjPtr vm, ret = 0; cleanup: - /* Restore max migration bandwidth */ - if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) == 0) { - qemuMonitorSetMigrationSpeed(priv->mon, saveMigBandwidth); - priv->migMaxBandwidth = saveMigBandwidth; - qemuDomainObjExitMonitorWithDriver(driver, vm); - } - VIR_FORCE_CLOSE(pipeFD[0]); VIR_FORCE_CLOSE(pipeFD[1]); virCommandFree(cmd); -- 1.7.4.4

3 3

[libvirt] [PATCH] fix two bugs in bridge_driver.c
by Hu Tao 11 Nov '11

11 Nov '11

steps to reproduce: 1. having a network xml file(named default.xml) like this one: <network> <name>default</name> <uuid>c5322c4c-81d0-4985-a363-ad6389780d89</uuid> <bridge name="virbr0" /> <forward/> <ip address="192.168.122.1" netmask="255.255.255.0"> <dhcp> <range start="192.168.122.2" end="192.168.122.254" /> </dhcp> </ip> </network> in /etc/libvirt/qemu/networks/, and mark it as autostart: $ ls -l /etc/libvirt/qemu/networks/autostart total 0 lrwxrwxrwx 1 root root 14 Oct 12 14:02 default.xml -> ../default.xml 2. start libvirtd and the device virbr0 is not automatically up. The reason is that the function virNetDevExists is now returns 1 if the device exists, comparing to the former one returns 0 if the device exists. But with only this fix will cause a segmentation fault(the same steps as above) that is fixed by the second chunk of code. --- src/network/bridge_driver.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 32cceb0..951b5aa 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -214,7 +214,7 @@ networkFindActiveConfigs(struct network_driver *driver) { /* If bridge exists, then mark it active */ if (obj->def->bridge && - virNetDevExists(obj->def->bridge) == 0) { + virNetDevExists(obj->def->bridge) == 1) { obj->active = 1; /* Try and read dnsmasq/radvd pids if any */ @@ -1815,8 +1815,10 @@ networkStartNetworkVirtual(struct network_driver *driver, if (!save_err) save_err = virSaveLastError(); - ignore_value(virNetDevTapDelete(macTapIfName)); - VIR_FREE(macTapIfName); + if (macTapIfName) { + ignore_value(virNetDevTapDelete(macTapIfName)); + VIR_FREE(macTapIfName); + } err0: if (!save_err) -- 1.7.3.1

3 2

[libvirt] [PATCH] build: drop useless dirent.h includes
by Eric Blake 11 Nov '11

11 Nov '11

* .gnulib: Update to latest, for improved syntax-check. * src/lxc/lxc_container.c (includes): Drop unused include. * src/network/bridge_driver.c: Likewise. * src/node_device/node_device_linux_sysfs.c: Likewise. * src/openvz/openvz_driver.c: Likewise. * src/qemu/qemu_conf.c: Likewise. * src/storage/storage_backend_iscsi.c: Likewise. * src/storage/storage_backend_mpath.c: Likewise. * src/uml/uml_conf.c: Likewise. * src/uml/uml_driver.c: Likewise. --- I'm not sure whether to include this in 0.9.7. On the one hand, this is pretty trivial; on the other hand, I hate making more .gnulib updates than necessary after release candidates have been posted, in case an unintended regression sneaks in from a half-baked gnulib change. But looking at the 22 patches, I'm not seeing anything likely to impact libvirt besides the new syntax check rule. * .gnulib 0031e4f...e56e96f (22): > maint.mk: silence new syntax check > Doc about floating-point and math API. > stdalign tests: Skip the test when compiled by Sun C. > ansi-c++-opt: Complete the 2011-06-05 change. > * doc/posix-headers/stdalign.texi (stdalign.h): Mention Sun review ID. > copysignl: Fix result for zero argument on HP-UX 11 with HP C. > update from texinfo > ldexp, ldexpf, ldexpl: Enhance tests. > math tests: Cosmetics. > fma*: Simplify test. > Tests for module 'fmal'. > New module 'fmal'. > Tests for module 'fmaf'. > New module 'fmaf'. > Tests for module 'fma'. > New module 'fma'. > Extend gl_MATHFUNC. > New modules 'at-internal', 'openat-h', split off from module 'openat'. > maint.mk: also prohibit inclusion of dirent.h without use > ldexpl tests: Avoid test failure on MSVC 9. > New modules 'at-internal', 'openat-h', split off from module 'openat'. > openat: Include <stdbool.h>. .gnulib | 2 +- src/lxc/lxc_container.c | 1 - src/network/bridge_driver.c | 1 - src/node_device/node_device_linux_sysfs.c | 3 +-- src/openvz/openvz_driver.c | 1 - src/qemu/qemu_conf.c | 1 - src/storage/storage_backend_iscsi.c | 1 - src/storage/storage_backend_mpath.c | 3 +-- src/uml/uml_conf.c | 1 - src/uml/uml_driver.c | 1 - 10 files changed, 3 insertions(+), 12 deletions(-) diff --git a/.gnulib b/.gnulib index 0031e4f..e56e96f 160000 --- a/.gnulib +++ b/.gnulib @@ -1 +1 @@ -Subproject commit 0031e4f6353cc7077a9d0dad0c793bd6e3dc7aaa +Subproject commit e56e96fe20f72586e9ec5c528b9a9a06daa2ecc6 diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index c4e5f28..c2484a7 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -35,7 +35,6 @@ #include <sys/stat.h> #include <unistd.h> #include <mntent.h> -#include <dirent.h> /* Yes, we want linux private one, for _syscall2() macro */ #include <linux/unistd.h> diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 445c3cb..e897b32 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -25,7 +25,6 @@ #include <sys/types.h> #include <sys/poll.h> -#include <dirent.h> #include <limits.h> #include <string.h> #include <stdio.h> diff --git a/src/node_device/node_device_linux_sysfs.c b/src/node_device/node_device_linux_sysfs.c index 844231a..d352800 100644 --- a/src/node_device/node_device_linux_sysfs.c +++ b/src/node_device/node_device_linux_sysfs.c @@ -2,7 +2,7 @@ * node_device_hal_linuc.c: Linux specific code to gather device data * not available through HAL. * - * Copyright (C) 2009-2010 Red Hat, Inc. + * Copyright (C) 2009-2011 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -32,7 +32,6 @@ #include "memory.h" #include "logging.h" #include "virfile.h" -#include <dirent.h> #define VIR_FROM_THIS VIR_FROM_NODEDEV diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c index 69ff444..4eed8ad 100644 --- a/src/openvz/openvz_driver.c +++ b/src/openvz/openvz_driver.c @@ -30,7 +30,6 @@ #include <sys/types.h> #include <sys/poll.h> -#include <dirent.h> #include <limits.h> #include <string.h> #include <stdio.h> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index d1bf075..0cf921f 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -23,7 +23,6 @@ #include <config.h> -#include <dirent.h> #include <string.h> #include <limits.h> #include <sys/types.h> diff --git a/src/storage/storage_backend_iscsi.c b/src/storage/storage_backend_iscsi.c index 99e69c9..354f99b 100644 --- a/src/storage/storage_backend_iscsi.c +++ b/src/storage/storage_backend_iscsi.c @@ -32,7 +32,6 @@ #include <regex.h> #include <fcntl.h> #include <unistd.h> -#include <dirent.h> #include <sys/stat.h> #include "virterror_internal.h" diff --git a/src/storage/storage_backend_mpath.c b/src/storage/storage_backend_mpath.c index 4f3add3..f09ce9b 100644 --- a/src/storage/storage_backend_mpath.c +++ b/src/storage/storage_backend_mpath.c @@ -1,7 +1,7 @@ /* * storage_backend_mpath.c: storage backend for multipath handling * - * Copyright (C) 2009-2010 Red Hat, Inc. + * Copyright (C) 2009-2011 Red Hat, Inc. * Copyright (C) 2009-2008 Dave Allan * * This library is free software; you can redistribute it and/or @@ -25,7 +25,6 @@ #include <unistd.h> #include <stdio.h> -#include <dirent.h> #include <fcntl.h> #include <libdevmapper.h> diff --git a/src/uml/uml_conf.c b/src/uml/uml_conf.c index f2bdd74..e06eb90 100644 --- a/src/uml/uml_conf.c +++ b/src/uml/uml_conf.c @@ -23,7 +23,6 @@ #include <config.h> -#include <dirent.h> #include <string.h> #include <limits.h> #include <sys/types.h> diff --git a/src/uml/uml_driver.c b/src/uml/uml_driver.c index 772e1c6..35b73b6 100644 --- a/src/uml/uml_driver.c +++ b/src/uml/uml_driver.c @@ -25,7 +25,6 @@ #include <sys/types.h> #include <sys/poll.h> -#include <dirent.h> #include <limits.h> #include <string.h> #include <stdio.h> -- 1.7.4.4

1 1

[libvirt] [PATCH] xenapi: remove unused variable
by Eric Blake 11 Nov '11

11 Nov '11

CC libvirt_driver_xenapi_la-xenapi_driver.lo xenapi/xenapi_driver.c: In function 'xenapiDomainGetVcpus': xenapi/xenapi_driver.c:1209:21: error: variable 'cpus' set but not used [-Werror=unused-but-set-variable] * src/xenapi/xenapi_driver.c (xenapiDomainGetVcpus): Silence compiler warning. --- Pushing under the build-breaker rule. src/xenapi/xenapi_driver.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/src/xenapi/xenapi_driver.c b/src/xenapi/xenapi_driver.c index d454589..a835b2d 100644 --- a/src/xenapi/xenapi_driver.c +++ b/src/xenapi/xenapi_driver.c @@ -1206,7 +1206,7 @@ xenapiDomainGetVcpus (virDomainPtr dom, xen_vm_set *vms = NULL; xen_vm vm = NULL; xen_string_string_map *vcpu_params = NULL; - int nvcpus = 0, cpus = 0, i; + int nvcpus = 0, i; virDomainInfo domInfo; virNodeInfo nodeInfo; virVcpuInfoPtr ifptr; @@ -1221,9 +1221,7 @@ xenapiDomainGetVcpus (virDomainPtr dom, _("Couldn't fetch Domain Information")); return -1; } - if (xenapiNodeGetInfo(dom->conn, &nodeInfo) == 0) - cpus = nodeInfo.cpus; - else { + if (xenapiNodeGetInfo(dom->conn, &nodeInfo) != 0) { xenapiSessionErrorHandler(dom->conn, VIR_ERR_INTERNAL_ERROR, _("Couldn't fetch Node Information")); return -1; -- 1.7.7.1

1 0

[libvirt] 0.9.7 virsh console regression?
by Albert W. Hopkins 11 Nov '11

11 Nov '11

Hi folks, I have a few "headless" qemu domains that use serial consoles. Typically i connect to the consoles with # virsh console <domain> However with 0.9.7 I get Connected to domain gentoo-base Escape character is ^] error: internal error character device (null) is not using a PTY I am still able to connect to the console if i go into the virt-manager gui and use the "gui" console, but I'd rather not do that as sometimes I don't have access to the gui. Is this a regression or am I expected to do some kind of migration on my domains. These are qemu guests running on Gentoo Linux. An xml dump of a typical domain follows: <domain type='kvm'> <name>base</name> <uuid>b4a528dd-4c31-03ca-bdde-795c4c38592d</uuid> <memory>524288</memory> <currentMemory>61440</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc-0.12'>hvm</type> <kernel>/var/lib/libvirt/images/vmlinuz</kernel> <cmdline>root=/dev/vda1 rootfstype=ext4 quiet console=ttyS0 TERM=vt100</cmdline> <boot dev='hd'/> <bootmenu enable='no'/> </os> <features> <acpi/> <pae/> </features> <cpu match='exact'> <model>Nehalem</model> <vendor>Intel</vendor> <feature policy='require' name='tm2'/> <feature policy='require' name='est'/> <feature policy='require' name='monitor'/> <feature policy='require' name='ss'/> <feature policy='require' name='vme'/> <feature policy='require' name='rdtscp'/> <feature policy='require' name='ht'/> <feature policy='require' name='ds'/> <feature policy='require' name='pbe'/> <feature policy='require' name='tm'/> <feature policy='require' name='vmx'/> <feature policy='require' name='ds_cpl'/> <feature policy='require' name='xtpr'/> <feature policy='require' name='acpi'/> <feature policy='require' name='x2apic'/> </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/base.qcow'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <interface type='network'> <mac address='52:54:00:06:84:c0'/> <source network='default'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </memballoon> </devices> </domain> Thanks in advance, -a

3 2

[libvirt] Open Source Virtualization and Cloud at FOSDEM
by Mark McLoughlin 11 Nov '11

11 Nov '11

Hey, Here's one for the calendar - a 2 day track at FOSDEM devoted to Open Source Virtualization and Cloud. Hope to see you there! :) Cheers, Mark. -------- Forwarded Message -------- > From: Thierry Carrez <thierry(a)openstack.org> > To: openstack(a)lists.launchpad.net <openstack(a)lists.launchpad.net> > Subject: [Openstack] OpenStack at FOSDEM > Date: Fri, 11 Nov 2011 11:34:22 +0100 > > Hi everyone, > > Our OpenStack devroom was accepted for FOSDEM, February 4-5, 2012 in > Brussels. It was actually grouped with other "Open Source virtualization > and cloud" projects in a giant devroom (550-seat auditorium) that lasts > the full 2 days ! > > Expect a CFP in the coming weeks... > > See other devrooms at: > http://fosdem.org/2012/devrooms_for_2012 > > -- > Thierry Carrez (ttx) > Release Manager, OpenStack > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack(a)lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp

1 0

[libvirt] Long QEMU main loop pauses during migration (to file) under heavy load
by Daniel P. Berrange 11 Nov '11

11 Nov '11

Libvirt recently introduced a change to the way it does 'save to file' with QEMU. Historically QEMU has a 32MB/s I/O limit on migration by default. When saving to file, we didn't want any artificial limit, but rather to max out the underlying storage. So when doing save to file, we set a large bandwidth limit (INT64_MAX / (1024 * 1024)) so it is effectively unlimited. After doing this, we discovered that the QEMU monitor was becoming entirely blocked. It did not even return from the 'migrate' command until migration was complete despite the 'detach' flag being set. This was a bug in libvirt, because we passed a plain file descriptor which does not support EAGAIN. Thank you POSIX. Libvirt has another mode where it uses an I/O helper command so get O_DIRECT, and in this mode we pass a pipe() FD to QEMU. After ensuring that this pipe FD really does have O_NONBLOCK set, we still saw some odd behaviour. I'm not sure whether what I describe can neccessarily be called a QEMU bug, but I wanted to raise it for discussion anyway.... The sequence of steps is - libvirt sets qemu migration bandwidth to "unlimited" - libvirt opens a pipe() and sets O_NONBLOCK on the write end - libvirt spawns libvirt-iohelper giving it the target file on disk, and the read end of the pipe - libvirt does 'getfd migfile' monitor command to give QEMU the write end of the pipe - libvirt does 'migrate fd:migfile -d' to run migration - In parallel - QEMU is writing to the pipe (which is non-blocking) - libvirt_helper reading the pipe & writing to disk with O_DIRECT The initial 'migrate' command detaches into the background OK, and libvirt can enter its loop doing 'query-migrate' frequently to monitor progress. Initially this works fine, but at some points during the migration, QEMU will get "stuck" for a very long time and not respond to the monitor (or indeed the mainloop at all). These blackouts are anywhere from 10 to 20 seconds long. Using a combination of systemtap, gdb and strace I managed to determine out the following - Most of the qemu_savevm_state_iterate() calls complete in 10-20 ms - Reasonably often a qemu_savevm_state_iterate() call takes 300-400 ms - Fairly rarely a qemu_savevm_state_iterate() call takes 10-20 *seconds* - I can see EAGAIN from the FD QEMU is migrating from - hence most of the iterations are quite short. - In the 10-20 second long calls, no EAGAIN is seen for the entire period. - The host OS in general is fairly "laggy", presumably due to the high rate of direct I/O being performed by the I/O helper, and bad schedular tuning IIUC, there are two things which will cause a qemu_savevm_state_iterate() call to return - Getting EAGAIN on the migration FD - Hitting the max bandwidth limit We have set effectively unlimited bandwidth, so everything relies on the EAGAIN behaviour. If the OS is doing a good job at scheduling processes & I/O, then this seems to work reasonably well. If the OS is highly loaded and becoming less responsive to scheduling apps, then QEMU gets itself into a bad way. What I think is happening is that the OS is giving too much time to the I/O helper process that is reading the other end of the pipe given to QEMU, and then doing the O_DIRECT to disk. Thus in the shorter-than-normal windows of time when QEMU itself is scheduled by the OS, the pipe is fairly empty, so QEMU does not see EAGAIN for a very long period of wallclock time. So we get into a case where QEMU sees 10-20 second gaps betweeen iterations of the main loop. Having a non-inifinite max-bandwidth for the migration, would likely mitigate this to some extent, but I still think it'd be possible to get QEMU into these pathelogical conditions under high load for a host. Is this a scenario we need to worry about for QEMU ? On the one hand it seems like it is a rare edge case in OS behaviour overall. On the other hand, times when a host is highly loaded and non-responsive are exactly the times when a mgmt app might want to save a guest to disk, or migrate it elsewhere. Which would mean we need QEMU to behave as well as possible in these adverse conditions. Thus should we consider having an absolute bound on the execution time of qemu_savevm_state_iterate(), independant of EAGAIN & bandwidth limits, to ensure the main loop doesn't get starved ? Or perhaps moving migration to a separate thread, out of the mainloop is what we need to strive for ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 1

[libvirt] [PATCH 0/3] Guest NUMA topology support - v1
by Bharata B Rao 11 Nov '11

11 Nov '11

Hi, This patch series adds support for specifying NUMA topology for guests. <cpu> ... <topology sockets='2' cores='4' threads='2'/> <numa> <cell cpus='0-7' mems='512000'/> <cell cpus='8-15' mems='512000'/> </numa> ... </cpu> This change allows libvirt to generate -numa options for QEMU/KVM. Changes since v0 ---------------- - Patch re-organization as per danpb's comments. - Use of virBufferAsPrintf instead of snprintf as per danpb's comments. - Use "cell" instead of "node" as per danpb's suggestion. - Add a helper to truncate virBuffer as per Eric's suggestion. - Add documentation. - Add testcases - Add basic validity check for cpus specified in <numa> ... </numa> Testing -------- The patches pass all tests except domainschema test. I think this is not a real failure, but the test is probably failing to pickup the right domaincommon.rng file. Will investigate further. TEST: domainschematest ........................................ 40 ........................................ 80 .........!.............................. 120 ........................................ 160 .................!...................... 200 ........................................ 240 ........................................ 280 ........................................ 320 ... 323 FAILED daemon-conf fails, but it fails even without my patches too. I guess my patches are really affecting it. TEST: daemon-conf .....!!!!!!...!!!!!!!!!!!!!!!!!!!./daemon-conf: line 98: kill: (7811) - No such process ! 34 FAILED v0 -- - https://www.redhat.com/archives/libvir-list/2011-October/msg00025.html RFC --- - http://permalink.gmane.org/gmane.comp.emulators.libvirt/44626 Regards, Bharata.

2 11

[libvirt] [RFC PATCH 0/8 v3] Summary on block IO throttle
by Lei Li 11 Nov '11

11 Nov '11

Changes since V2 - Implement the Python binding support for setting blkio throttling. - Implement --current --live --config options support to unify the libvirt API. - Add changes in docs and tests. - Some changes suggested by Adam Litke, Eric Blake, Daniel P. Berrange. - Change the XML schema. - API name to virDomain{Set, Get}BlockIoTune. - Parameters changed to make them more self-explanatory. - virsh command name to blkdeviotune. - And other fixups. Changes since V1 - Implement the support to get the block io throttling for a device as read only connection - QMP/HMP. - Split virDomainBlockIoThrottle into two separate functions virDomainSetBlockIoThrottle - Set block I/O limits for a device - Requires a connection in 'write' mode. - Limits (info) structure passed as an input parameter virDomainGetBlockIoThrottle - Get the current block I/O limits for a device - Works on a read-only connection. - Current limits are written to the output parameter (reply). - And Other fixups suggested by Adam Litke, Daniel P. Berrange. - For dynamically allocate the blkiothrottle struct, I will fix it when implement --current --live --config options support. Today libvirt supports the cgroups blkio-controller, which handles proportional shares and throughput/iops limits on host block devices. blkio-controller does not support network file systems (NFS) or other QEMU remote block drivers (curl, Ceph/rbd, sheepdog) since they are not host block devices. QEMU I/O throttling works with all types of drive and can be applied independently to each drive attached to a guest and supports throughput/iops limits. To help add QEMU I/O throttling support to libvirt, we plan to complete it with add new API virDomain{Set, Get}BlockIoThrottle(), new command 'blkdeviotune' and Python bindings. Notes: Now all the planed features were implemented (#1#2 were implemented by Zhi Yong Wu), the previous comments were all fixed up too. And the qemu part patches have been accepted upstream just now and are expected to be part of the QEMU 1.1 release, git tree from Zhi Yong: http://repo.or.cz/w/qemu/kevin.git/shortlog/refs/heads/block 1) Enable the blkio throttling in xml when guest is starting up. Add blkio throttling in xml as follows: <disk type='file' device='disk'> ... <iotune> <total_bytes_sec>nnn</total_bytes_sec> ... </iotune> ... </disk> 2) Enable blkio throttling setting at guest running time. virsh blkdeviotune <domain> <device> [--total_bytes_sec<number>] [--read_bytes_sec<number>] \ [--write_bytes_sec<number>] [--total_iops_sec<number>] [--read_iops_sec<number>] [--write_iops_sec<number>] 3) The support to get the current block i/o throttling for a device - HMP/QMP. virsh blkiothrottle <domain> <device> total_bytes_sec: read_bytes_sec: write_bytes_sec: total_iops_sec: read_iops_sec: write_iops_sec: 4) Python binding support for setting blkio throttling. 5) --current --live --config options support to unify the libvirt API. virsh blkdeviotune <domain> <device> [--total_bytes_sec <number>] [--read_bytes_sec <number>] [--write_bytes_sec <number>] [--total_iops_sec <number>] [--read_iops_sec <number>] [--write_iops_sec <number>] [--config] [--live] [--current] daemon/remote.c | 87 +++++++ docs/formatdomain.html.in | 30 ++ docs/schemas/domaincommon.rng | 24 + include/libvirt/libvirt.h.in | 25 ++ python/generator.py | 2 python/libvirt-override-api.xml | 16 + python/libvirt-override.c | 85 +++++++ src/conf/domain_conf.c | 101 ++++++++ src/conf/domain_conf.h | 12 src/driver.h | 18 + src/libvirt.c | 115 +++++++++ src/libvirt_public.syms | 2 src/qemu/qemu_command.c | 33 ++ src/qemu/qemu_driver.c | 217 ++++++++++++++++++ src/qemu/qemu_monitor.c | 36 ++ src/qemu/qemu_monitor.h | 10 src/qemu/qemu_monitor_json.c | 191 +++++++++++++++ src/qemu/qemu_monitor_json.h | 10 src/qemu/qemu_monitor_text.c | 152 ++++++++++++ src/qemu/qemu_monitor_text.h | 10 src/remote/remote_driver.c | 81 ++++++ src/remote/remote_protocol.x | 39 +++ src/remote_protocol-structs | 34 ++ src/util/xml.h | 3 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune.args | 4 tests/qemuxml2argvdata/qemuxml2argv-blkdeviotune.xml | 36 ++ tests/qemuxml2argvtest.c | 2 tests/qemuxml2xmltest.c | 2 tools/virsh.c | 146 ++++++++++++ tools/virsh.pod | 23 + 30 files changed, 1540 insertions(+), 6 deletions(-) -- Lei

4 6

[libvirt] Problem with listDomains() in Xen
by PREETHI RAMESH 11 Nov '11

11 Nov '11

This question concerns the usage of the listDomains(). When I run this piece of code in KVM, it works perfectly fine but throws an array out of bounds exception in Xen. Connect conn=null; conn = new Connect("xen:///", true); int[] id = conn.listDomains(); System.out.println("lD of VM " +id[0]); Answer I'd got: Well, your code assumes that id.length is >= 1, but listDomains() can return an empty array when there are no active domains known to libvirt. So you need to check id.length before accessing any element in the array. Follow up- I tried accessing the length of the array and it's 0 all the time. And there are active domains available. In fact, I'm able to getUUID from the domain name. Other functions work fine too. Am I missing something?Can someone please help me? Thanks!

1 0