Re: Need KVM HD settings advice
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=400,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. For that, you create lvm volume of size of your hard drive, convert your image to raw .img and write over lvm volume. 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 -- Vladimir
Re: Need KVM HD settings advice
On Tue, Sep 20, 2011 at 3:05 AM, Vladimir Mosgalin mosga...@vm10124.spb.edu 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=400,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.
Re: Need KVM HD settings advice
On Sep 20, 2011, at 14:48 , Nico Kadel-Garcia wrote: On Tue, Sep 20, 2011 at 3:05 AM, Vladimir Mosgalin mosga...@vm10124.spb.edu 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=400,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
