On Tue, Sep 20, 2011 at 3:05 AM, Vladimir Mosgalin
<[log in to unmask]> wrote:
> Hi Todd And Margo Chester!
>
>  On 2011.09.19 at 18:03:08 -0700, Todd And Margo Chester wrote next:
>
>> What I need help with is getting the optimum performance
>> settings while converting over my old hard (virtual) drive.
>>
>> This is what I have gathered from these parts as to the best
>> settings:
>>
>> - controller: virtio
>> - kvm option: cache=none
>> - qcow2 disk format with metadata preallocation
>> - create your disk image with:
>>      qemu-img create -f qcow2 -o \
>>      size=40000000000,preallocation=metadata vdisk.img
>
> If you don't need snapshots and such, you might get better performance
> with LVM volumes for storing images, connected as "raw images". At least
> that's only thing that I'm using in production and it works well.

LVM has its uses. But the ability to re-allocate space without having
to manipulate your partition tables is *vital* in a dynamic
environmemnt, and it's a lot easier to do with image files.

Tuning nthe partition the images reside on, now *that* is invaluable.
Turn off noatime, use a fast and simple file system. LVM can be handy
for doing backup snapshots when you're re-arranging and migrating
filesystem images, but its management of additional space and release
of the snapshots is somewhat undermanaged.

One kicker you may not have noticed: if your disk for your KVM server
has 4096 byte blocks, you *REALLY, REALLY, REALLY* wan the virtualized
OS to use partitions aligned on 4096 byte block boundaries. The
virtualized OS's have no way to detect the underlying disk layout, and
can burn incredible amounts of resources re-aligning everything for
disk access.

> For that, you create lvm volume of size of your hard drive, convert your
> image to raw .img and write over lvm volume.

See above. Details can matter.

> Storing images in filesystem is flexible, of course, but I believe it's
> too risky on random power off or hang/reset and performance might be lower.
>
>> And, I am vague how a *.qcow file/drive and a *.img file/drive
>> relate.
>
> .img is (usually) simple raw image, copy of hard disk, and qcow is
> qemu-specific format with various features.
> http://en.wikipedia.org/wiki/Qcow
> http://wiki.qemu.org/download/qemu-doc.html#disk_005fimages

Yeah, the disk image format depends extensively on the virtualization
technology in use.