On Sep 20, 2011, at 14:48 , Nico Kadel-Garcia wrote: > On Tue, Sep 20, 2011 at 3:05 AM, Vladimir Mosgalin > <[email protected]> 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.
I disagree. There's no need to manipulate partition tables in order to provide LVs as backing store to VMs. Extending a LV is as easy as enlarging a backing file. LV data alignment can be specified, at least with SL6. I see no disadvantage in using LVs for VM backing store, other than having to learn about LVM. And it does avoid the significant overhead of going through a second filesystem layer. At least potentially, it also avoids double caching. Since we introduced Linux-(Xen-)hosted VMs with SL5, we too have backed all our VMs - hundreds - with logical volumes. And we haven't changed that with SL6 and KVM. > Tuning nthe partition the images reside on, now *that* is invaluable. > Turn off noatime, use a fast and simple file system. Well, just don't use a filesystem... NB noatime tunes the filesystem, not the block device (partition or LV) it resides on. [...] -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany
