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 at xunil.at> wrote: From: Stefan G. Weichinger <lists at xunil.at> Subject: [libvirt-users] qcow2 performance To: libvirt-users at 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 at redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20120206/97bade16/attachment.htm>
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 at redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 222 bytes Desc: OpenPGP digital signature URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20120206/a26f560d/attachment.sig>
Umberto Carrara
2012-Feb-06 14:06 UTC
[libvirt-users] trouble compile libvirt on slackware 13.37
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.
###################################
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20120206/443780a5/attachment.htm>
On Mon, Feb 6, 2012 at 2:07 AM, Stefan G. Weichinger <lists at xunil.at> wrote:> Am 06.02.2012 03:24, schrieb Trey Dockendorf: >> I wouldn't consider this definitive, but I wrote an article doing >> tests on qcow2 with the variables being preallocation and caching. >> Essentially preallocation + no-cache is the fastest. ?Article here, >> http://itscblog.tamu.edu/improve-disk-io-performance-in-kvm/. ?As of >> virt-manager-0.9.0 the only way to generate the qcow2 with >> preallocation is via command line. ?Details of how are in the article. > > Additional question: > > Doesn't pre-allocation lose its meaning as soon as the image-file is > fully allocated (I mean as soon as it is as big as its maximum size was > defined at start)? > > >Sending response back to list incase someone finds it useful. Preallocation works so that when you create a 100GB image it takes up 100GB from the start. This helps performance because without preallocation the disk would only take up space of whatever is stored on it. So each time you add files the filesystem as to grow the image. With qcow2 the preallocation is just metadata. I've found that ls -lh will show the size correctly but something like "df -h" won't reflect the size of those images, nor will "du -h". - Trey