- Devel - libvirt List Archives

[libvirt] [PATCH] schedinfo: add missing documentation
by Taku Izumi 19 Aug '11

19 Aug '11

This patch adds the missing documentation about the scheduler parameter "vcpu_period" and "vcpu_quota". Signed-off-by: Taku Izumi <izumi.taku(a)jp.fujitsu.com> --- tools/virsh.pod | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) Index: libvirt/tools/virsh.pod =================================================================== --- libvirt.orig/tools/virsh.pod +++ libvirt/tools/virsh.pod @@ -712,7 +712,9 @@ I<domain-id> Allows you to show (and set) the domain scheduler parameters. The parameters available for each hypervisor are: -LXC, QEMU/KVM (posix scheduler): cpu_shares +LXC (posix scheduler) : cpu_shares + +QEMU/KVM (posix scheduler): cpu_shares, vcpu_period, vcpu_quota Xen (credit scheduler): weight, cap @@ -729,6 +731,10 @@ Therefore, -1 is a useful shorthand for B<Note>: The weight and cap parameters are defined only for the XEN_CREDIT scheduler and are now I<DEPRECATED>. +B<Note>: The vcpu_period parameter has a valid value range of 1000-1000000 or +0, and the vcpu_quota parameter has a valid value range of 1000-1844674407370955 +or less than 0. + =item B<screenshot> I<domain-id> [I<imagefilepath>] [I<--screen> B<screenID>] Takes a screenshot of a current domain console and stores it into a file.

2 1

[libvirt] [PATCH] maint: ignore generated file
by Eric Blake 19 Aug '11

19 Aug '11

I did 'git add .' while in the middle of 'make syntax-check', and it picked up a temporary file that should not be committed. * .gitignore: Ignore sc_* from syntax check. --- Pushing under the trivial rule. .gitignore | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index e8b2dbf..39ecd6d 100644 --- a/.gitignore +++ b/.gitignore @@ -53,6 +53,7 @@ /po/* /proxy/ /python/generator.py.stamp +/sc_* /src/libvirt_iohelper /src/locking/qemu-sanlock.conf /src/remote/*_client_bodies.h -- 1.7.4.4

1 0

[libvirt] [RFC] Should libvirt be a proxy for migration data
by Jiri Denemark 18 Aug '11

18 Aug '11

Hi all, Currently when we start a non-tunneled migration, data go straight from source qemu to destination qemu. This is nice in that there is no additional overhead but it also has several disadvantages. If the communication between source and destination qemu breaks, we only get unexpected error message from qemu with no glue about what happened. Another issue is that if qemu cannot send migration data, we cannot cancel the migration because migrate_cancel blocks until all buffers with migration data queued up for transmission are written into the socket. That said, I think we should act as a proxy between source and destination qemu so that we can detect and report normal errors (such as connection reset by peer) and cancel migration at any time. Since we have virNetSocket and we already use that for connecting to destination qemu, we should use it for proxying migration data as well. This approach also has some disadvantages, e.g., a single libvirt thread instead of several qemu processes will now send migration data from all domains that are being migrated. However, I feel like the gain is bigger than the downside. And we already do the same for tunneled migration anyway. Any objections? Jirka

2 2

Re: [libvirt] [Qemu-devel] Killing block migration in qemu?
by Anthony Liguori 18 Aug '11

18 Aug '11

On 08/17/2011 11:51 AM, Paolo Bonzini wrote: > Hi all, > > following discussions yesterday with Juan Quintela and Marcelo Tosatti, > here is my humble proposal: remove block migration from qemu master. +1 I was going to propose the same thing after the conference actually. Regards, Anthony Liguori

1 0

[libvirt] [PATCH 0/5 v2] Some rearrangement & additions to pid file handling/locking
by Daniel P. Berrange 18 Aug '11

18 Aug '11

An update to: https://www.redhat.com/archives/libvir-list/2011-August/msg00349.html Changes in v2: - Fix all docs & code bugs from previous review

4 13

[libvirt] RFC (V2) New virDomainBlockPull API family to libvirt
by Adam Litke 18 Aug '11

18 Aug '11

Here are the patches to implement the BlockPull/BlockJob API as discussed and agreed to. I am testing with a python script (included for completeness as the final patch). The qemu monitor interface is not expected to change in the future. Stefan is planning to submit placeholder commands for upstream qemu until the generic streaming support is implemented. Changes since V1: - Make virDomainBlockPullAbort() and virDomainGetBlockPullInfo() into a generic BlockJob interface. - Added virDomainBlockJobSetSpeed() - Rename VIR_DOMAIN_EVENT_ID_BLOCK_PULL event to fit into block job API - Add bandwidth argument to virDomainBlockPull() Summary of changes since first generation patch series: - Qemu dropped incremental streaming so remove libvirt incremental BlockPull() API - Rename virDomainBlockPullAll() to virDomainBlockPull() - Changes required to qemu monitor handlers for changed command names -- To help speed the provisioning process for large domains, new QED disks are created with backing to a template image. These disks are configured with copy on read such that blocks that are read from the backing file are copied to the new disk. This reduces I/O over a potentially costly path to the backing image. In such a configuration, there is a desire to remove the dependency on the backing image as the domain runs. To accomplish this, qemu will provide an interface to perform sequential copy on read operations during normal VM operation. Once all data has been copied, the disk image's link to the backing file is removed. The virDomainBlockPull API family brings this functionality to libvirt. virDomainBlockPull() instructs the hypervisor to stream the entire device in the background. Progress of this operation can be checked with the function virDomainBlockJobInfo(). An ongoing stream can be cancelled with virDomainBlockJobAbort(). virDomainBlockJobSetSpeed() allows you to limit the bandwidth that the operation may consume. An event (VIR_DOMAIN_EVENT_ID_BLOCK_JOB) will be emitted when a disk has been fully populated or if a BlockPull() operation was terminated due to an error. This event is useful to avoid polling on virDomainBlockJobInfo() for completion and could also be used by the security driver to revoke access to the backing file when it is no longer needed. make check: PASS make syntax-check: PASS make -C tests valgrind: PASS [PATCH 1/8] Add new API virDomainBlockPull* to headers [PATCH 2/8] virDomainBlockPull: Implement the main entry points [PATCH 3/8] Add virDomainBlockPull support to the remote driver [PATCH 4/8] Implement virDomainBlockPull for the qemu driver [PATCH 5/8] Enable the virDomainBlockPull API in virsh [PATCH 6/8] Enable virDomainBlockPull in the python API. [PATCH 7/8] Asynchronous event for BlockJob completion [PATCH 8/8] Test the blockJob/BlockPull API

6 22

Re: [libvirt] [Qemu-devel] Killing block migration in qemu?
by Stefan Hajnoczi 18 Aug '11

18 Aug '11

On Wed, Aug 17, 2011 at 5:51 PM, Paolo Bonzini <pbonzini(a)redhat.com> wrote: > following discussions yesterday with Juan Quintela and Marcelo Tosatti, here > is my humble proposal: remove block migration from qemu master. It seems to > me that keeping block migration is going to slow down further improvements > on migration. The main problems are: > > 1) there are very good reasons to move migration to a separate thread. Only > a limited amount of extra locking, perhaps none is needed in order to do so > for RAM and devices. But the block drivers pretty much need to run under > the I/O thread lock, and coroutines will not help if the I/O thread is taken > by another thread. It's hard/unreliable/pointless to ping-pong migration > between threads. The image streaming approach will also run in the I/O thread for the mid-term future. Is the problem that the block migration code today is too tied into the actual migration code path and therefore stops from using it when migration happens in a separate thread? > > 2) there already are plans to reimplement block migration... it's called > streaming :) and not coincidentially it reuses some of the block migration > code. What are the concrete issues with the existing block migration code? I'm not disagreeing that we should move to a streaming approach but I simply don't know the details of the existing block migration code. > Here is how it would go: This sounds reasonable. In fact we can do both pre-copy and post-copy block migration using streaming (+mirroring). Stefan

2 1

[libvirt] [PATCH] qemu: Initialize GnuTLS
by Michal Privoznik 18 Aug '11

18 Aug '11

When spice_tls is set but listen_tls is not, we don't initialize GnuTLS library. So any later gnutls call (e.g. during migration, where we initialize a certificate) will access uninitialized GnuTLS internal structs and throws an error. Although, we might now initialize GnuTLS twice, it is safe according to the documentation: This function can be called many times, but will only do something the first time. --- src/qemu/qemu_driver.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 421a98e..5fe20b6 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -44,6 +44,7 @@ #include <sys/ioctl.h> #include <sys/un.h> #include <byteswap.h> +#include <gnutls/gnutls.h> #include "qemu_driver.h" @@ -537,6 +538,15 @@ qemudStartup(int privileged) { } VIR_FREE(driverConf); + if (qemu_driver->spiceTLS) { + /* Initialize GnuTLS. If it was initialized before, + * it doesn't hurt. From GnuTLS documentation: + * This function can be called many times, + * but will only do something the first time. + */ + gnutls_global_init(); + } + /* We should always at least have the 'nop' manager, so * NULLs here are a fatal error */ @@ -754,6 +764,9 @@ qemudShutdown(void) { qemuProcessAutoDestroyShutdown(qemu_driver); + if (qemu_driver->spiceTLS) + gnutls_global_deinit(); + VIR_FREE(qemu_driver->configDir); VIR_FREE(qemu_driver->autostartDir); VIR_FREE(qemu_driver->logDir); -- 1.7.3.4

2 1

[libvirt] [PATCH 0/2] Libvirt-java event handling
by js＠alien8.de 18 Aug '11

18 Aug '11

From: Julian Stecklina <jsteckli(a)os.inf.tu-dresden.de> I noticed that event handling in the libvirt Java bindings is incomplete. The first patch adds required data types and constants. The second relaxes the visibility of the Domain constructor, otherwise Callbacks are kind of useless. Regards, Julian Julian Stecklina (2): Allow different types of callbacks (just as the C API). Allow to construct Domain objects from inside callbacks. src/main/java/org/libvirt/Connect.java | 3 ++- src/main/java/org/libvirt/Domain.java | 2 +- src/main/java/org/libvirt/jna/Libvirt.java | 22 ++++++++++++++++++++-- 3 files changed, 23 insertions(+), 4 deletions(-) -- 1.7.3.4

3 4

Re: [libvirt] patch for disk migration verbose progress
by Eric Blake 17 Aug '11

17 Aug '11

[re-adding the list] On 08/17/2011 12:30 AM, Tom Vijlbrief wrote: > Hi Eric > > This is the complete patch including json (not tested) and a typo correction > in an error message... > > Tom > ---------- Doorgestuurd bericht ---------- > Van: "Tom Vijlbrief"<tom(a)nomadbsd.v7f.eu> > Datum: 17 aug. 2011 08:23 > Onderwerp: mon.patch > Aan:<tvijlbrief(a)gmail.com> > > > mon.patch > Thanks again for taking the time to contribute. It is easier to work with patches generated by 'git format-patch' (and 'git send-email' is a nice wrapper that both formats the patch and mails it to the list); as written, your patch had no commit message, so I had to invent one. I also added you to AUTHORS; let me know if I need to update any preferred spellings. > > # NB, must pass the --listen flag to the libvirtd process for this to Is this a stray line in your email, or is it pointing out a further issue? > diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c > index 2a9a078..618a45c 100644 > --- a/src/qemu/qemu_monitor_json.c > +++ b/src/qemu/qemu_monitor_json.c > @@ -1894,6 +1894,31 @@ qemuMonitorJSONGetMigrationStatusReply(virJSONValuePtr reply, > _("migration was active, but RAM 'total' data was missing")); > return -1; > } > + > + virJSONValuePtr disk = virJSONValueObjectGet(ret, "disk"); > + if (!disk) { > + return 0; > + } > + > + unsigned long long t; Our style tends to float declarations to the top, C89 style, even though this is valid as written (we require C99 for other reasons). > + if (virJSONValueObjectGetNumberUlong(disk, "transferred",&t)< 0) { > + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", > + _("disk migration was active, but DISK 'transferred' data was missing")); > + return -1; > + } > + (*transferred)+= t; > + if (virJSONValueObjectGetNumberUlong(disk, "remaining",&t)< 0) { > + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", > + _("disk migration was active, but DISK 'remaining' data was missing")); > + return -1; > + } > + (*remaining)+= t; I tweaked spacing between operators (yeah, it doesn't help that thunderbird corrupted spacing even worse in my reply to your mail). And the () are redundant; this can safely be: *remaining += t; > + if (virJSONValueObjectGetNumberUlong(disk, "total",&t)< 0) { > + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", > + _("disk migration was active, but DISK 'total' data was missing")); > + return -1; > + } > + (*total)+= t; > } > > return 0; > diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c > index 7bf733d..fef6f36 100644 > --- a/src/qemu/qemu_monitor_text.c > +++ b/src/qemu/qemu_monitor_text.c > @@ -149,7 +149,7 @@ int qemuMonitorTextIOProcess(qemuMonitorPtr mon ATTRIBUTE_UNUSED, > passwd = strstr(start, PASSWORD_PROMPT); > if (passwd) { > #if DEBUG_IO > - VIR_DEBUG("Seen a passwowrd prompt [%s]", data + used); > + VIR_DEBUG("Seen a password prompt [%s]", data + used); > #endif > if (msg->passwordHandler) { > int i; > @@ -1183,6 +1183,9 @@ cleanup: > #define MIGRATION_TRANSFER_PREFIX "transferred ram: " > #define MIGRATION_REMAINING_PREFIX "remaining ram: " > #define MIGRATION_TOTAL_PREFIX "total ram: " > +#define MIGRATION_DISK_TRANSFER_PREFIX "transferred disk: " > +#define MIGRATION_DISK_REMAINING_PREFIX "remaining disk: " > +#define MIGRATION_DISK_TOTAL_PREFIX "total disk: " > > int qemuMonitorTextGetMigrationStatus(qemuMonitorPtr mon, > int *status, > @@ -1246,6 +1249,7 @@ int qemuMonitorTextGetMigrationStatus(qemuMonitorPtr mon, > goto cleanup; > } > *remaining *= 1024; > + tmp = end; > > if (!(tmp = strstr(tmp, MIGRATION_TOTAL_PREFIX))) > goto done; > @@ -1257,7 +1261,53 @@ int qemuMonitorTextGetMigrationStatus(qemuMonitorPtr mon, > goto cleanup; > } > *total *= 1024; > + tmp = end; > + > + /* > + * Check for Optional Disk Migration status > + */ > + > + unsigned long long disk_transferred= 0; > + unsigned long long disk_remaining= 0; > + unsigned long long disk_total= 0; > + > + if (!(tmp = strstr(tmp, MIGRATION_DISK_TRANSFER_PREFIX))) > + goto done; > + tmp += strlen(MIGRATION_DISK_TRANSFER_PREFIX); > > + if (virStrToLong_ull(tmp,&end, 10,&disk_transferred)< 0) { > + qemuReportError(VIR_ERR_INTERNAL_ERROR, > + _("cannot parse disk migration data transferred statistic %s"), tmp); > + goto cleanup; > + } > + disk_transferred *= 1024; > + (*transferred)+= disk_transferred; For one less assignment, I merged these two lines into: *transferred += disk_transferred * 1024; > + tmp = end; > + > + if (!(tmp = strstr(tmp, MIGRATION_DISK_REMAINING_PREFIX))) > + goto done; > + tmp += strlen(MIGRATION_DISK_REMAINING_PREFIX); > + > + if (virStrToLong_ull(tmp,&end, 10,&disk_remaining)< 0) { > + qemuReportError(VIR_ERR_INTERNAL_ERROR, > + _("cannot parse disk migration data remaining statistic %s"), tmp); > + goto cleanup; > + } > + disk_remaining *= 1024; > + (*remaining)+= disk_remaining; > + tmp = end; > + > + if (!(tmp = strstr(tmp, MIGRATION_DISK_TOTAL_PREFIX))) > + goto done; > + tmp += strlen(MIGRATION_DISK_TOTAL_PREFIX); > + > + if (virStrToLong_ull(tmp,&end, 10,&disk_total)< 0) { > + qemuReportError(VIR_ERR_INTERNAL_ERROR, > + _("cannot parse disk migration data total statistic %s"), tmp); > + goto cleanup; > + } > + disk_total *= 1024; > + (*total)+= disk_total; > } > } ACK and pushed with those tweaks. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

1 0