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
