- Devel - libvirt List Archives

[libvirt] [libvirt-snmp][PATCH] Change source location in .spec file to the one from libvirt.org
by Michal Privoznik 02 Mar '11

02 Mar '11

--- I've created the snmp dir: http://www.libvirt.org/sources/snmp/ libvirt-snmp.spec.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libvirt-snmp.spec.in b/libvirt-snmp.spec.in index 6082a7a..85c5025 100644 --- a/libvirt-snmp.spec.in +++ b/libvirt-snmp.spec.in @@ -6,7 +6,7 @@ Summary: SNMP functionality for libvirt Group: Development/Libraries License: GPLv3 URL: http://libvirt.org -Source0: libvirt-snmp-%{version}.tar.gz +Source0: http://libvirt.org/sources/snmp/libvirt-snmp-%{version}.tar.gz BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) BuildRequires: net-snmp-perl net-snmp net-snmp-utils net-snmp-devel libvirt-devel -- 1.7.4

2 1

[libvirt] [PATCH 1/2] qemu: add -incoming fd:n capability checking
by Eric Blake 02 Mar '11

02 Mar '11

* src/qemu/qemu_capabilities.h (QEMUD_CMD_FLAG_MIGRATE_QEMU_FD): New enum value. * src/qemu/qemu_capabilities.c (qemuCapsComputeCmdFlags): Populate flags according to qemu version. * tests/qemuhelptest.c (mymain): Adjust test. --- I feel a bit dirty relying on just a version test for whether -incoming fd:n is supported, but it's no different than the existing code for -incoming unix:path which was added about the same time. Unfortunately, 'qemu -help' doesn't list which particular protocols it supports for -incoming. src/qemu/qemu_capabilities.c | 6 +++++- src/qemu/qemu_capabilities.h | 1 + tests/qemuhelptest.c | 12 ++++++++---- 3 files changed, 14 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 913fbf7..3d10b42 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -943,6 +943,8 @@ qemuCapsComputeCmdFlags(const char *help, * Handling of -incoming arg with varying features * -incoming tcp (kvm >= 79, qemu >= 0.10.0) * -incoming exec (kvm >= 80, qemu >= 0.10.0) + * -incoming unix (qemu >= 0.12.0) + * -incoming fd (qemu >= 0.12.0) * -incoming stdio (all earlier kvm) * * NB, there was a pre-kvm-79 'tcp' support, but it @@ -952,8 +954,10 @@ qemuCapsComputeCmdFlags(const char *help, if (version >= 10000) { flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_TCP; flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_EXEC; - if (version >= 12000) + if (version >= 12000) { flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_UNIX; + flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_FD; + } } else if (kvm_version >= 79) { flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_TCP; if (kvm_version >= 80) diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 83afd9b..ee648f0 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -82,6 +82,7 @@ enum qemuCapsFlags { QEMUD_CMD_FLAG_VGA_QXL = (1LL << 45), /* The 'qxl' arg for '-vga' */ QEMUD_CMD_FLAG_SPICE = (1LL << 46), /* Is -spice avail */ QEMUD_CMD_FLAG_VGA_NONE = (1LL << 47), /* The 'none' arg for '-vga' */ + QEMUD_CMD_FLAG_MIGRATE_QEMU_FD = (1LL << 48), /* -incoming fd:n */ }; virCapsPtr qemuCapsInit(virCapsPtr old_caps); diff --git a/tests/qemuhelptest.c b/tests/qemuhelptest.c index 553abbc..18a71fa 100644 --- a/tests/qemuhelptest.c +++ b/tests/qemuhelptest.c @@ -286,7 +286,8 @@ mymain(int argc, char **argv) QEMUD_CMD_FLAG_BOOT_MENU | QEMUD_CMD_FLAG_NAME_PROCESS | QEMUD_CMD_FLAG_SMBIOS_TYPE | - QEMUD_CMD_FLAG_VGA_NONE, + QEMUD_CMD_FLAG_VGA_NONE | + QEMUD_CMD_FLAG_MIGRATE_QEMU_FD, 12001, 0, 0); DO_TEST("qemu-kvm-0.12.1.2-rhel60", QEMUD_CMD_FLAG_VNC_COLON | @@ -324,7 +325,8 @@ mymain(int argc, char **argv) QEMUD_CMD_FLAG_SMBIOS_TYPE | QEMUD_CMD_FLAG_VGA_QXL | QEMUD_CMD_FLAG_SPICE | - QEMUD_CMD_FLAG_VGA_NONE, + QEMUD_CMD_FLAG_VGA_NONE | + QEMUD_CMD_FLAG_MIGRATE_QEMU_FD, 12001, 1, 0); DO_TEST("qemu-kvm-0.12.3", QEMUD_CMD_FLAG_VNC_COLON | @@ -360,7 +362,8 @@ mymain(int argc, char **argv) QEMUD_CMD_FLAG_NESTING | QEMUD_CMD_FLAG_NAME_PROCESS | QEMUD_CMD_FLAG_SMBIOS_TYPE | - QEMUD_CMD_FLAG_VGA_NONE, + QEMUD_CMD_FLAG_VGA_NONE | + QEMUD_CMD_FLAG_MIGRATE_QEMU_FD, 12003, 1, 0); DO_TEST("qemu-kvm-0.13.0", QEMUD_CMD_FLAG_VNC_COLON | @@ -403,7 +406,8 @@ mymain(int argc, char **argv) QEMUD_CMD_FLAG_NAME_PROCESS | QEMUD_CMD_FLAG_SMBIOS_TYPE | QEMUD_CMD_FLAG_SPICE | - QEMUD_CMD_FLAG_VGA_NONE, + QEMUD_CMD_FLAG_VGA_NONE | + QEMUD_CMD_FLAG_MIGRATE_QEMU_FD, 13000, 1, 0); return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; -- 1.7.3.3

4 15

[libvirt] there is a mistake in "libvirt development guide, chapter 4.1: list domains"
by SanitYey o 02 Mar '11

02 Mar '11

int i; int numDomains; char **inactiveDomains; numDomains = virConnectNumOfDefinedDomains(conn); inactiveDomains = malloc(sizeof(char *) * numDomains); numDomains = virConnectListDomains(conn, inactiveDomains, numDomains); printf("Inactive domain names:\n"); for (i = 0 ; i < numDomains ; i++) { printf(" %s\n", inactiveDomains[i]); free(inactiveDomains[i]); } free(inactiveDomains); Example 4.5. Listing inactive domains There should use "virConnectListDefinedDomains" for inactive domains.

2 1

[libvirt] [PATCH V3] Add libxenlight driver
by Jim Fehlig 01 Mar '11

01 Mar '11

Hi All, Another update to the libxenlight driver for Xen 4.1. The primary change in this version is reservation of vnc ports within the driver when autoport=yes. libxenlight does not provide a mechanism to retrieve the auto-selected port and the 'vncunused' option is not in upstream qemu anyhow, so best to avoid it. I've tested the following operations on both pv and hvm linux guests: define, undefine, start, create, shutdown, reboot, destroy, getinfo, and dumpxml. I've also done some minimal testing with virt-manager, e.g. starting a previously defined domain and connecting to its graphical console. Thanks for your review and comments. Regards, Jim

1 0

[libvirt] [PATCH] qemu: only request sound cgroup ACL when required
by Eric Blake 28 Feb '11

28 Feb '11

When a SPICE or VNC graphics controller is present, and sound is piggybacked over a channel to the graphics device rather than directly accessing host hardware, then there is no need to grant host hardware access to that qemu process. * src/qemu/qemu_cgroup.c (qemuSetupCgroup): Prevent sound with spice, and with vnc when vnc_allow_host_audio is 0. Reported by Daniel Berrange. --- Daniel noticed this while reviewing the audit code - the audit proved that we were allowing more resources than necessary. src/qemu/qemu_cgroup.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index b39b5e1..e71d3fa 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -241,7 +241,11 @@ int qemuSetupCgroup(struct qemud_driver *driver, goto cleanup; } - if (vm->def->nsounds) { + if (vm->def->nsounds && + (!vm->def->ngraphics || + ((vm->def->graphics[0]->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC && + driver->vncAllowHostAudio) || + (vm->def->graphics[0]->type == VIR_DOMAIN_GRAPHICS_TYPE_SDL)))) { rc = virCgroupAllowDeviceMajor(cgroup, 'c', DEVICE_SND_MAJOR); qemuDomainCgroupAudit(vm, cgroup, "allow", "major", "sound", rc == 0); -- 1.7.4

2 2

[libvirt] [PATCH] Add check for kill() to fix build of cgroups on win32
by Daniel P. Berrange 28 Feb '11

28 Feb '11

The kill() function doesn't exist on Win32, so it needs to be checked for at build time & code disabled in cgroups * configure.ac: Check for kill() * src/util/cgroup.c: Stub out virCGroupKill* functions when kill() isn't available --- configure.ac | 2 +- src/util/cgroup.c | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index bd509f3..a58ee4e 100644 --- a/configure.ac +++ b/configure.ac @@ -120,7 +120,7 @@ AC_MSG_RESULT([$have_cpuid]) dnl Availability of various common functions (non-fatal if missing), dnl and various less common threadsafe functions AC_CHECK_FUNCS_ONCE([cfmakeraw regexec sched_getaffinity getuid getgid \ - initgroups posix_fallocate mmap \ + initgroups posix_fallocate mmap kill \ getmntent_r getgrnam_r getpwuid_r]) dnl Availability of pthread functions (if missing, win32 threading is diff --git a/src/util/cgroup.c b/src/util/cgroup.c index 6af3af1..c5b8cdd 100644 --- a/src/util/cgroup.c +++ b/src/util/cgroup.c @@ -1307,6 +1307,8 @@ int virCgroupGetFreezerState(virCgroupPtr group, char **state) "freezer.state", state); } + +#ifdef HAVE_KILL static int virCgroupKillInternal(virCgroupPtr group, int signum, virHashTablePtr pids) { int rc; @@ -1520,3 +1522,21 @@ int virCgroupKillPainfully(virCgroupPtr group) VIR_DEBUG("Complete %d", rc); return rc; } + +#else /* HAVE_KILL */ +int virCgroupKill(virCgroupPtr group ATTRIBUTE_UNUSED, + int signum ATTRIBUTE_UNUSED) +{ + return -ENOSYS; +} +int virCgroupKillRecursive(virCgroupPtr group ATTRIBUTE_UNUSED, + int signum ATTRIBUTE_UNUSED) +{ + return -ENOSYS; +} + +int virCgroupKillPainfully(virCgroupPtr group ATTRIBUTE_UNUSED) +{ + return -ENOSYS; +} +#endif /* HAVE_KILL */ -- 1.7.4

2 1

[libvirt] [PATCH v4 0/2] Add support for multiple serial ports into the Xen driver
by Michal Novotny 28 Feb '11

28 Feb '11

Hi, this is the patch to add support for multiple serial ports to the libvirt Xen driver. It support both old style (serial = "pty") and new style (serial = [ "/dev/ttyS0", "/dev/ttyS1" ]) definition and tests for xml2sexpr, sexpr2xml and xmconfig have been added as well. Written and tested on RHEL-5 Xen dom0 and working as designed but the Xen version have to have patch for RHBZ #614004 but this patch is for upstream version of libvirt. Also, this patch is addressing issue described in RHBZ #670789. Differences between v2 and v3: * Fixed serial port handling if we have definition of device in non-zero port number * Added second test for first port undefined (i.e. port value > 0 for just one serial port) This between v3 and v4 (this one): * Traversal lookup to ensure the right order of the serial ports has been implemented * Parsing and finding new available port number for parallel port has been added as well Michal Signed-off-by: Michal Novotny <minovotn(a)redhat.com> Michal Novotny (2): Fix virDomainChrDefParseTargetXML() port value handling for serial and parallel ports Add support for multiple serial ports into the Xen driver src/conf/domain_conf.c | 24 +++- src/xenxs/xen_sxpr.c | 92 ++++++++++-- src/xenxs/xen_xm.c | 148 +++++++++++++++++--- .../sexpr2xml-fv-serial-dev-2-ports.sexpr | 1 + .../sexpr2xml-fv-serial-dev-2-ports.xml | 53 +++++++ .../sexpr2xml-fv-serial-dev-2nd-port.sexpr | 1 + .../sexpr2xml-fv-serial-dev-2nd-port.xml | 49 +++++++ tests/sexpr2xmltest.c | 2 + .../test-fullvirt-serial-dev-2-ports.cfg | 25 ++++ .../test-fullvirt-serial-dev-2-ports.xml | 55 +++++++ .../test-fullvirt-serial-dev-2nd-port.cfg | 25 ++++ .../test-fullvirt-serial-dev-2nd-port.xml | 53 +++++++ tests/xmconfigtest.c | 2 + .../xml2sexpr-fv-serial-dev-2-ports.sexpr | 1 + .../xml2sexpr-fv-serial-dev-2-ports.xml | 44 ++++++ .../xml2sexpr-fv-serial-dev-2nd-port.sexpr | 1 + .../xml2sexpr-fv-serial-dev-2nd-port.xml | 40 ++++++ tests/xml2sexprtest.c | 2 + 18 files changed, 578 insertions(+), 40 deletions(-) create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-serial-dev-2-ports.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-serial-dev-2-ports.xml create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-serial-dev-2nd-port.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-serial-dev-2nd-port.xml create mode 100644 tests/xmconfigdata/test-fullvirt-serial-dev-2-ports.cfg create mode 100644 tests/xmconfigdata/test-fullvirt-serial-dev-2-ports.xml create mode 100644 tests/xmconfigdata/test-fullvirt-serial-dev-2nd-port.cfg create mode 100644 tests/xmconfigdata/test-fullvirt-serial-dev-2nd-port.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-serial-dev-2-ports.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-serial-dev-2-ports.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-serial-dev-2nd-port.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-serial-dev-2nd-port.xml -- 1.7.3.2

2 4

[libvirt] [libvirt-php 1/3] build: add error message
by Lyre 28 Feb '11

28 Feb '11

* configure.ac: issue an error message when tools not found * libvirt-php.spec.in: add BuildRequires: libxslt --- configure.ac | 18 +++++++++++++++--- libvirt-php.spec.in | 1 + 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 8d81b9d..ed1e65f 100644 --- a/configure.ac +++ b/configure.ac @@ -82,9 +82,21 @@ AC_ARG_WITH([xml-catalog-file], AC_SUBST([XML_CATALOG_FILE]) # External programs to generate documentation -AC_PATH_PROG([XSLTPROC], [xsltproc], [/usr/bin/xsltproc]) -AC_PATH_PROG([XMLLINT], [xmllint], [/usr/bin/xmllint]) -AC_PATH_PROG([XMLCATALOG], [xmlcatalog], [/usr/bin/xmlcatalog]) +AC_PATH_PROG([XSLTPROC], [xsltproc], [no]) +if test "x$XSLTPROC" = "xno"; then + AC_MSG_ERROR([xsltproc not found]) +fi + +AC_PATH_PROG([XMLLINT], [xmllint], [no]) +if test "x$XMLLINT" = "xno"; then + AC_MSG_ERROR([xmllint not found]) +fi + +AC_PATH_PROG([XMLCATALOG], [xmlcatalog], [no]) +if test "x$XMLCATALOG" = "xno"; then + AC_MSG_ERROR([xmlcatalog not found]) +fi + dnl Specific dir for HTML output ? AC_ARG_WITH([html-dir], [AC_HELP_STRING([--with-html-dir=path], diff --git a/libvirt-php.spec.in b/libvirt-php.spec.in index 465532c..9507927 100644 --- a/libvirt-php.spec.in +++ b/libvirt-php.spec.in @@ -26,6 +26,7 @@ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root BuildRequires: php-devel BuildRequires: libvirt-devel >= %{req_libvirt_version} BuildRequires: libxml2-devel +BuildRequires: libxslt %if 0%{?suse_version} BuildRequires: xhtml-dtd %else -- 1.7.1

4 8

Re: [libvirt] [Qemu-devel] Re: [patch 2/3] Add support for live block copy
by Dor Laor 28 Feb '11

28 Feb '11

On 02/27/2011 07:25 PM, Anthony Liguori wrote: > On 02/27/2011 10:02 AM, Dor Laor wrote: >> On 02/27/2011 03:49 PM, Anthony Liguori wrote: >>> On 02/27/2011 03:55 AM, Dor Laor wrote: >>>> What about a simpler approach were QMP events will be written to a >>>> event-log-file (or even named pipe). >>> >>> The management tool can just use a small daemon that does nothing other >>> than write QMP events to a log. There's no real need for this code to >>> live in QEMU. >>> >> >> IIUC in case the management daemon will run qemu using named pipe for >> qmp it will happen automatically. > > No, the event model is changing (it was always intended to change > though). Events will need explicit registration so it's necessary to > have bidirectional communication. But the mgmt->qemu direction is only about event registration, it's not valuable info. It's a simpler approach than relaying on another config file and it is safer than having a separate mgmt daemon to log these events. Cross posting to libvirt-list to hear their view. > > So you can't just do -qmp foo -chardev file:event.log,id=foo. You won't > actually see most of the events. > > Regards, > > Anthony Liguori > >> If you agree to this approach it will simplify the more complex config >> file option (although it is nice to have as independent option for >> single hosts managed by simpler mgmts) >> >>> Since events are posted, even if we wrote it in QEMU, the event wouldn't >>> be guaranteed on disk by the time the event invocation returns. >>> >>> Regards, >>> >>> Anthony Liguori >>> >> >> > >

1 0

Re: [libvirt] blkio cgroup
by Vivek Goyal 26 Feb '11

26 Feb '11

On Fri, Feb 18, 2011 at 03:42:45PM +0100, Dominik Klein wrote: > Hi Vivek > > I don't know whether you follow the libvirt list, I assume you don't. So > I thought I'd forward you an E-Mail involving the blkio controller and a > terrible situation arising from using it (maybe in a wrong way). > > I'd truely appreciate it if you read it and commented on it. Maybe I did > something wrong, but maybe also I found a bug in some way. Hi Dominik, Thanks for forwarding me this mail. Yes, I am not on libvir-list. I have just now subscribed. Few questions inline. > -------- Original Message -------- > Subject: Re: [libvirt] [PATCH 0/6 v3] Add blkio cgroup support > Date: Fri, 18 Feb 2011 14:42:51 +0100 > From: Dominik Klein <dk(a)in-telegence.net> > To: libvir-list(a)redhat.com > > Hi > > back with some testing results. > > >> how about the start Guest with option "cache=none" to bypass pagecache? > >> This should help i think. > > > > I will read up on where to set that and give it a try. Thanks for the hint. > > So here's what I did and found out: > > The host system has 2 12 core CPUs and 128 GB of Ram. > > I have 8 test VMs named kernel1 to kernel8. Each VM has 4 VCPUs, 2 GB of > RAm and one disk, which is an lv on the host. Cache mode is "none": So you have only one root SATA disk and setup a linear logical volume on that? I not, can you give more info about the storage configuration? - I am assuming you are using CFQ on your underlying physical disk. - What kernel version are you testing with. - Cache=none mode is good which should make all the IO O_DIRECT on host and should show up as SYNC IO on CFQ without losing io context info. The onlly probelm is intermediate dm layer and if it is changing the io context somehow. I am not sure at this point of time. - Is it possible to capture 10-15 second blktrace on your underlying physical device. That should give me some idea what's happening. - Can you also try setting /sys/block/<disk>/queue/iosched/group_isolation=1 on your underlying physical device where CFQ is running and see if it makes any difference. > > for vm in kernel1 kernel2 kernel3 kernel4 kernel5 kernel6 kernel7 > kernel8; do virsh dumpxml $vm|grep cache; done > <driver name='qemu' type='raw' cache='none'/> > <driver name='qemu' type='raw' cache='none'/> > <driver name='qemu' type='raw' cache='none'/> > <driver name='qemu' type='raw' cache='none'/> > <driver name='qemu' type='raw' cache='none'/> > <driver name='qemu' type='raw' cache='none'/> > <driver name='qemu' type='raw' cache='none'/> > <driver name='qemu' type='raw' cache='none'/> > > My goal is to give more I/O time to kernel1 and kernel2 than to the rest > of the VMs. > > mount -t cgroup -o blkio none /mnt > cd /mnt > mkdir important > mkdir notimportant > > echo 1000 > important/blkio.weight > echo 100 > notimportant/blkio.weight > for vm in kernel3 kernel4 kernel5 kernel6 kernel7 kernel8; do > cd /proc/$(pgrep -f "qemu-kvm.*$vm")/task > for task in *; do > /bin/echo $task > /mnt/notimportant/tasks > done > done > > for vm in kernel1 kernel2; do > cd /proc/$(pgrep -f "qemu-kvm.*$vm")/task > for task in *; do > /bin/echo $task > /mnt/important/tasks > done > done > > Then I used cssh to connect to all 8 VMs and execute > dd if=/dev/zero of=testfile bs=1M count=1500 > in all VMs simultaneously. > > Results are: > kernel1: 47.5593 s, 33.1 MB/s > kernel2: 60.1464 s, 26.2 MB/s > kernel3: 74.204 s, 21.2 MB/s > kernel4: 77.0759 s, 20.4 MB/s > kernel5: 65.6309 s, 24.0 MB/s > kernel6: 81.1402 s, 19.4 MB/s > kernel7: 70.3881 s, 22.3 MB/s > kernel8: 77.4475 s, 20.3 MB/s > > Results vary a little bit from run to run, but it is nothing > spectacular, as weights of 1000 vs. 100 would suggest. > > So I went and tried to throttle I/O of kernel3-8 to 10MB/s instead of > weighing I/O. First I rebooted everything so that no old configuration > of cgroup was left in place and then setup everything except the 100 and > 1000 weight configuration. > > quote from blkio.txt: > ------------ > - blkio.throttle.write_bps_device > - Specifies upper limit on WRITE rate to the device. IO rate is > specified in bytes per second. Rules are per deivce. Following is > the format. > > echo "<major>:<minor> <rate_bytes_per_second>" > > /cgrp/blkio.write_bps_device > ------------- > > for vm in kernel1 kernel2 kernel3 kernel4 kernel5 kernel6 kernel7 > kernel8; do ls -lH /dev/vdisks/$vm; done > brw-rw---- 1 root root 254, 23 Feb 18 13:45 /dev/vdisks/kernel1 > brw-rw---- 1 root root 254, 24 Feb 18 13:45 /dev/vdisks/kernel2 > brw-rw---- 1 root root 254, 25 Feb 18 13:45 /dev/vdisks/kernel3 > brw-rw---- 1 root root 254, 26 Feb 18 13:45 /dev/vdisks/kernel4 > brw-rw---- 1 root root 254, 27 Feb 18 13:45 /dev/vdisks/kernel5 > brw-rw---- 1 root root 254, 28 Feb 18 13:45 /dev/vdisks/kernel6 > brw-rw---- 1 root root 254, 29 Feb 18 13:45 /dev/vdisks/kernel7 > brw-rw---- 1 root root 254, 30 Feb 18 13:45 /dev/vdisks/kernel8 > > /bin/echo 254:25 10000000 > > /mnt/notimportant/blkio.throttle.write_bps_device > /bin/echo 254:26 10000000 > > /mnt/notimportant/blkio.throttle.write_bps_device > /bin/echo 254:27 10000000 > > /mnt/notimportant/blkio.throttle.write_bps_device > /bin/echo 254:28 10000000 > > /mnt/notimportant/blkio.throttle.write_bps_device > /bin/echo 254:29 10000000 > > /mnt/notimportant/blkio.throttle.write_bps_device > /bin/echo 254:30 10000000 > > /mnt/notimportant/blkio.throttle.write_bps_device > /bin/echo 254:30 10000000 > > /mnt/notimportant/blkio.throttle.write_bps_device > > Then I ran the previous test again. This resulted in an ever increasing > load (last I checked was ~ 300) on the host system. (This is perfectly > reproducible). > > uptime > Fri Feb 18 14:42:17 2011 > 14:42:17 up 12 min, 9 users, load average: 286.51, 142.22, 56.71 Have you run top or something to figure out why load average is shooting up. I suspect that because of throttling limit, IO threads have been blocked and qemu is forking more IO threads. Can you just run top/ps and figure out what's happening. Again, is it some kind of linear volume group from which you have carved out logical volumes for each virtual machine? For throttling to begin with, can we do a simple test first. That is run a single virtual machine, put some throttling limit on logical volume and try to do READs. Once READs work, lets test WRITES and check why does system load go up. Thanks Vivek

5 39