[libvirt-users] qcow2 performance
Greets, I have to research performance-issues of a W2003-VM within KVM. Right now it's a qcow2-image-file w/ default settings within libvirt (configured by vmm ...) My question: what caching to use? writeback/writethrough/etc ... what to use for data integrity while not getting ultraslow performance? Found https://www.linuxfoundation.jp/jp_uploads/JLS2009/jls09_hellwig.pdf Is there any other list/doc what to use and why? Thanks, Stefan
Hello, The cache settings would also depend on the underlying storage. If you are planning to use something like ext4 partition on the local harddisk then cache=none would be suitable. It would be good to avoid cache=writeback on production environment as there no guarantees that the write actually got saved to harddisk. cache=writethrough though slower than writeback is the most recommended for the production environments. To get better performance it would be good to identify what additional performance can be extracted from the underlying storage subsystem. Thanks and Regards Saurav Lahiri Hexagrid Computing --- On Sun, 5/2/12, Stefan G. Weichinger <lists@xunil.at> wrote: From: Stefan G. Weichinger <lists@xunil.at> Subject: [libvirt-users] qcow2 performance To: libvirt-users@redhat.com Date: Sunday, 5 February, 2012, 18:31 Greets, I have to research performance-issues of a W2003-VM within KVM. Right now it's a qcow2-image-file w/ default settings within libvirt (configured by vmm ...) My question: what caching to use? writeback/writethrough/etc ... what to use for data integrity while not getting ultraslow performance? Found https://www.linuxfoundation.jp/jp_uploads/JLS2009/jls09_hellwig.pdf Is there any other list/doc what to use and why? Thanks, Stefan _______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Am 06.02.2012 09:59, schrieb SAURAV LAHIRI:
Hello, The cache settings would also depend on the underlying storage. If you are planning to use something like ext4 partition on the local harddisk then cache=none would be suitable.
Right now we try that, yes. As mentioned in the other msg I am currently not able to use cache=none, VM doesn't start that way ... still looking ... For now, yes, qcow2 on ext4.
It would be good to avoid cache=writeback on production environment as there no guarantees that the write actually got saved to harddisk.
cache=writethrough though slower than writeback is the most recommended for the production environments.
Right now I run "cache=default" ... what would that mean? (aio=threads works)
To get better performance it would be good to identify what additional performance can be extracted from the underlying storage subsystem.
Right now it looks more like the communication between the application and the client PCs is the bottleneck. Copying files from the VM over LAN is fast! So I assume I/O isn't the problem anymore. As mentioned I also chose "deadline"-scheduler for IO-scheduling on the host. We just try to check through everything to be able to nail it down on the software house delivering that application ... Thanks, Stefan
cache=default would set the cache to writethrough. Also to improve perfomance, you could try virtio based disks. http://www.linux-kvm.org/page/Virtio http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers Thanks and Regards Saurav Lahiri Hexagrid Computing --- On Mon, 6/2/12, Stefan G. Weichinger <lists@xunil.at> wrote: From: Stefan G. Weichinger <lists@xunil.at> Subject: Re: [libvirt-users] qcow2 performance To: "SAURAV LAHIRI" <saurav_lahiri@yahoo.com> Cc: libvirt-users@redhat.com Date: Monday, 6 February, 2012, 9:50 Am 06.02.2012 09:59, schrieb SAURAV LAHIRI:
Hello, The cache settings would also depend on the underlying storage. If you are planning to use something like ext4 partition on the local harddisk then cache=none would be suitable.
Right now we try that, yes. As mentioned in the other msg I am currently not able to use cache=none, VM doesn't start that way ... still looking ... For now, yes, qcow2 on ext4.
It would be good to avoid cache=writeback on production environment as there no guarantees that the write actually got saved to harddisk.
cache=writethrough though slower than writeback is the most recommended for the production environments.
Right now I run "cache=default" ... what would that mean? (aio=threads works)
To get better performance it would be good to identify what additional performance can be extracted from the underlying storage subsystem.
Right now it looks more like the communication between the application and the client PCs is the bottleneck. Copying files from the VM over LAN is fast! So I assume I/O isn't the problem anymore. As mentioned I also chose "deadline"-scheduler for IO-scheduling on the host. We just try to check through everything to be able to nail it down on the software house delivering that application ... Thanks, Stefan
Am 2012-02-07 10:51, schrieb SAURAV LAHIRI:
cache=default would set the cache to writethrough. Also to improve perfomance, you could try virtio based disks.
The VM already uses virtio-disk and -net, thanks. Currently it seems that the bottleneck is the application within the VM, so my tuning finds an end ;-) thanks
Hello, On 02/05/2012 11:31 PM, Stefan G. Weichinger wrote:
Greets,
I have to research performance-issues of a W2003-VM within KVM.
Right now it's a qcow2-image-file w/ default settings within libvirt (configured by vmm ...)
My question:
what caching to use?
writeback/writethrough/etc ... what to use for data integrity while not getting ultraslow performance?
A brief summary about qcow2 performance ... HTH http://www.linux-kvm.org/page/Qcow2 Regards, Andreas
Found
https://www.linuxfoundation.jp/jp_uploads/JLS2009/jls09_hellwig.pdf
Is there any other list/doc what to use and why?
Thanks, Stefan
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Am 06.02.2012 13:26, schrieb Andreas Kurz:
A brief summary about qcow2 performance ... HTH
thanks -... We are right now testing stuff. I can't set "cache=none" on the productive box ... but it works on my test-box w/ libvirt-0.9.8 and qemu-kvm-0.15.1-r1 (gentoo linux). Significant difference: my testbox runs kernel 3.2.2, productive box 3.0.0 ... could that make the difference? - Things done so far: latest virtio-drivers in w2003-vm deadline scheduler for hdd-IO data=journal for ext4 (ok? think safety) Should I mount the ext4 as ext3 instead? cache=default aio=threads - We are currently trying to figure out if the Windows-clients are the slower part in the game ... checking network etc. Thanks, greets ...
Customer seems happy now after I converted the image to raw-format, cache=none, aio=threads. Thanks all, Stefan
Hi, I'm trying to compile libvirt on slackware 13.37 with kernel 3.0 I think the problem is that i used wrong rpc lib i have used portablexdr-4.9.1 e libtirpc-0.2.2 this is the error : CCLD libvirt_driver_test.la CC libvirt_driver_remote_la-remote_driver.lo In file included from ../src/rpc/virnetprotocol.h:9:0, from ../src/rpc/virnetmessage.h:24, from ../src/rpc/virnetclient.h:27, from remote/remote_driver.c:31: /usr/include/tirpc/rpc/rpc.h:84:12: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:440:12: note: previous declaration of 'bindresvport' was here CC libvirt_driver_remote_la-remote_protocol.lo In file included from ./remote/remote_protocol.h:9:0, from ./remote/remote_protocol.c:7: /usr/include/tirpc/rpc/rpc.h:84:12: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:440:12: note: previous declaration of 'bindresvport' was here ./remote/remote_protocol.c: In function 'xdr_remote_vcpu_info': ./remote/remote_protocol.c:256:10: warning: implicit declaration of function 'xdr_uint64_t' [-Wimplicit-function-declaration] ./remote/remote_protocol.c:256:10: warning: nested extern declaration of 'xdr_uint64_t' [-Wnested-externs] ./remote/remote_protocol.c: In function 'xdr_remote_node_get_cells_free_memory_ret': ./remote/remote_protocol.c:606:48: error: 'xdr_uint64_t' undeclared (first use in this function) ./remote/remote_protocol.c:606:48: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [libvirt_driver_remote_la-remote_protocol.lo] Error 1 make[3]: Leaving directory `/opt/cluster/libvirt/libvirt-0.9.4/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/cluster/libvirt/libvirt-0.9.4/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/cluster/libvirt/libvirt-0.9.4' make: *** [all] Error 2 can someone help me? Thanks a lot -- ################################### Umberto Carrara servizi informatici alle aziende sistemistica e sviluppo via di Casa Cimi, 274/e Saltocchio 55100 (LU) voip: +39.05831802936 cel: +39.3384524491 http://umbertocarrara.it ################################### Privacy Il contenuto della presente e-mail ed i suoi allegati, sono diretti esclusivamente al destinatario e devono ritenersi riservati, con divieto di diffusione o di uso non conforme alle finalità per le quali la presente e-mail è stata inviata. Pertanto, ne è vietata la diffusione e la comunicazione da parte di soggetti diversi dal destinatario, ai sensi degli artt. 616 e ss. c.p. e D.lgs n. 196/03 Codice Privacy. Se la presente e-mail ed i suoi allegati sono stati ricevuti per errore, siete pregati di distruggere quanto ricevuto e di informare il mittente al presente indirizzo. ###################################
[when reporting an unrelated issue, please start a new thread rather than replying to an unrelated post] On 02/06/2012 07:06 AM, Umberto Carrara wrote:
Hi, I'm trying to compile libvirt on slackware 13.37 with kernel 3.0
I think the problem is that i used wrong rpc lib
i have used portablexdr-4.9.1 e libtirpc-0.2.2
this is the error :
CCLD libvirt_driver_test.la CC libvirt_driver_remote_la-remote_driver.lo In file included from ../src/rpc/virnetprotocol.h:9:0, from ../src/rpc/virnetmessage.h:24, from ../src/rpc/virnetclient.h:27, from remote/remote_driver.c:31: /usr/include/tirpc/rpc/rpc.h:84:12: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:440:12: note: previous declaration of 'bindresvport' was here
That's a bug in your rpc.h header, and not in libvirt proper. Slackware is not the only platform with this problem; compiling libvirt on cygwin hits the same issue. The message is only a warning, so you may safely ignore it.
CC libvirt_driver_remote_la-remote_protocol.lo In file included from ./remote/remote_protocol.h:9:0, from ./remote/remote_protocol.c:7: /usr/include/tirpc/rpc/rpc.h:84:12: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:440:12: note: previous declaration of 'bindresvport' was here ./remote/remote_protocol.c: In function 'xdr_remote_vcpu_info': ./remote/remote_protocol.c:256:10: warning: implicit declaration of function 'xdr_uint64_t' [-Wimplicit-function-declaration]
That's a bit tougher. I thought we had code in place to try to guarantee that we could find a 64-bit unsigned converter across the various flavors of RPC, but apparently we aren't configuring it correctly. Can you look in your /usr/include/rpc/xdr.h, and see what functions might be available? For example, other known spellings have been xdr_u_hyper, xdr_u_quad_t, or xdr_u_int64_t; if we can determine what name to check for in configure.ac (we're currently checking for xdr_u_int64_t), then we can patch src/remote/remote_protocol.x to honor that alternate spelling. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
In data lunedì, febbraio 06, 2012 09:47:57 PM, Eric Blake ha scritto:
[when reporting an unrelated issue, please start a new thread rather than replying to an unrelated post]
I'm sorry
That's a bit tougher. I thought we had code in place to try to guarantee that we could find a 64-bit unsigned converter across the various flavors of RPC, but apparently we aren't configuring it correctly. Can you look in your /usr/include/rpc/xdr.h, and see what functions might be available? For example, other known spellings have been xdr_u_hyper, xdr_u_quad_t, or xdr_u_int64_t; if we can determine what name to check for in configure.ac (we're currently checking for xdr_u_int64_t), then we can patch src/remote/remote_protocol.x to honor that alternate spelling.
thank you very much I solved by installing libtirpc from this http://ponce.cc/slackware/testing/libtirpc/ that compile fine thanks again Umberto -- ################################### Umberto Carrara servizi informatici alle aziende sistemistica e sviluppo via di Casa Cimi, 274/e Saltocchio 55100 (LU) voip: +39.05831802936 cel: +39.3384524491 http://umbertocarrara.it ################################### Privacy Il contenuto della presente e-mail ed i suoi allegati, sono diretti esclusivamente al destinatario e devono ritenersi riservati, con divieto di diffusione o di uso non conforme alle finalità per le quali la presente e-mail è stata inviata. Pertanto, ne è vietata la diffusione e la comunicazione da parte di soggetti diversi dal destinatario, ai sensi degli artt. 616 e ss. c.p. e D.lgs n. 196/03 Codice Privacy. Se la presente e-mail ed i suoi allegati sono stati ricevuti per errore, siete pregati di distruggere quanto ricevuto e di informare il mittente al presente indirizzo. ###################################
participants (5)
-
Andreas Kurz -
Eric Blake -
SAURAV LAHIRI -
Stefan G. Weichinger -
Umberto Carrara