4:31 p.m.
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
2:59 a.m.
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(a)xunil.at> wrote:
From: Stefan G. Weichinger <lists(a)xunil.at>
Subject: [libvirt-users] qcow2 performance
To: libvirt-users(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
7:50 a.m.
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
3:51 a.m.
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(a)xunil.at> wrote:
From: Stefan G. Weichinger <lists(a)xunil.at>
Subject: Re: [libvirt-users] qcow2 performance
To: "SAURAV LAHIRI" <saurav_lahiri(a)yahoo.com>
Cc: libvirt-users(a)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
8:56 a.m.
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
6:26 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
7:11 a.m.
Am 06.02.2012 13:26, schrieb Andreas Kurz:
A brief summary about qcow2 performance ... HTH
http://www.linux-kvm.org/page/Qcow2
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 ...
5:57 a.m.
Customer seems happy now after I converted the image to raw-format,
cache=none, aio=threads.
Thanks all, Stefan
8:06 a.m.
New subject: [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.
###################################
2:47 p.m.
New subject: [libvirt-users] trouble compile libvirt on slackware 13.37
[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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
1:11 p.m.
New subject: [libvirt-users] trouble compile libvirt on slackware 13.37
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.
###################################
4700
days inactive
4710
days old
10 comments
5 participants
participants (5)
-
Andreas Kurz -
Eric Blake -
SAURAV LAHIRI -
Stefan G. Weichinger -
Umberto Carrara