Hi Nico Kadel-Garcia!

 On 2011.09.20 at 08:48:06 -0400, Nico Kadel-Garcia wrote next:

> > 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.

Maybe. So far I've been okay doing it in few stages (grow LVM on host
with lvresize, grow second partition with fdisk on guest, which is lvm
partition too, use pvresize & lvresize on guest); I must admit it might
be a bit too complicated for some uses, but then again, on production
disks aren't growing *that* often.
Ability to do this without guest reboot depends on ability of guest to
re-read disk geometry, which is a bit independent of image format.

If I had to resize disks all the time for some reason then qcow images
might be better, but then again, in such environment I'd soon think of
SAN that stores images sparsingly, be that something hardware or just
solaris/openindiana zfs-backed up iscsi provider :)

How are qcow volumes compared to LVM-backed up images in terms of
performance, btw? Are there any good numbers? All I can find is
comparison between qcow & qcow2, or qcows with various features, or
information like "qcow used to suck, but with this commit fixing this
problem it's XX times faster on these operations!"

> 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.

Ugh. Tried some, won't try again ever. LVM snapshots behave so badly
under load so I just can't find a way to use them anywhere in
production. I tried deploying them in pure testing environment too, but
they were unable to handle even slightest load; depending on the way of
creating snapshots, either operating with drive with active snapshot
will cut IO performance by like 5 times, or operating with snapshot
itself will be that slow, and removing snapshot is insane load on
system, too.

Sadly, only full COW-based filesystems like zfs and btrfs can provide
adequately-working snapshots :-/

> 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.

Hm. But is that even needed, when modern operating systems try their
best to retain larger-scale alignment even without 4k sectors?
Like, all modern linux distributions and even windows 7 try to use 1MB
alignment for partitions. Since LVM itself doesn't destroy alignment, in
practice it will be aligned regardless.


-- 

Vladimir