[libvirt-users] qcow2 performance

[SAURAV LAHIRI]

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 at xunil.at> wrote:

From: Stefan G. Weichinger <lists at xunil.at>
Subject: Re: [libvirt-users] qcow2 performance
To: "SAURAV LAHIRI" <saurav_lahiri at yahoo.com>
Cc: libvirt-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20120207/ca68e2df/attachment.htm>