CentOS - Jun 2015 - LVM hatred, was Re: /boot on a separate partition?

Gordon Messmer gordon.messmer at gmail.com  Wed Jun 24 01:42:13 UTC 2015
> I wondered the same thing, especially in the context of someone who
> prefers virtual machines.  LV-backed VMs have *dramatically* better disk
> performance than file-backed VMs.
I did a bunch of testing of Raw, qcow2, and LV backed VM storage circa
Fedora 19/20 and found very little difference. What mattered most was
the (libvirt) cache setting, accessible by virsh edit the xml config
or virt-manager through the GUI. There have been a lot of
optimizations in libvirt and qemu that make qcow2 files perform
comparable to LVs.

For migrating VMs, it's easier if they're a file. And qcow2 snapshots
are more practical than LVM (thick) snapshots. The thin snapshots are
quite good though they take a lot of familiarity with setting them up.

-- 
Chris Murphy

On 06/25/2015 06:44 PM, Chris Murphy wrote:
> Gordon Messmer gordon.messmer at gmail.com  Wed Jun 24 01:42:13 UTC 2015
>
>> I wondered the same thing, especially in the context of someone who
>> prefers virtual machines.  LV-backed VMs have *dramatically* better
disk
>> performance than file-backed VMs.
> I did a bunch of testing of Raw, qcow2, and LV backed VM storage circa
> Fedora 19/20 and found very little difference. What mattered most was
> the (libvirt) cache setting, accessible by virsh edit the xml config
> or virt-manager through the GUI. There have been a lot of
Which setting did you find most effective?
> optimizations in libvirt and qemu that make qcow2 files perform
> comparable to LVs.
>
> For migrating VMs, it's easier if they're a file. And qcow2
snapshots
> are more practical than LVM (thick) snapshots. The thin snapshots are
> quite good though they take a lot of familiarity with setting them up.
>

-- 
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com

Am 26.06.2015 um 12:47 schrieb Steve Clark <sclark at
netwolves.com>:
> On 06/25/2015 06:44 PM, Chris Murphy wrote:
>> Gordon Messmer gordon.messmer at gmail.com  Wed Jun 24 01:42:13 UTC
2015
>> 
>>> I wondered the same thing, especially in the context of someone who
>>> prefers virtual machines.  LV-backed VMs have *dramatically* better
disk
>>> performance than file-backed VMs.
>> I did a bunch of testing of Raw, qcow2, and LV backed VM storage circa
>> Fedora 19/20 and found very little difference. What mattered most was
>> the (libvirt) cache setting, accessible by virsh edit the xml config
>> or virt-manager through the GUI. There have been a lot of
> Which setting did you find most effective?
Keep in mind - write caching can improve perf but 
also increases data loss on abnormal VM shutdowns

--
LF

On Fri, Jun 26, 2015 at 4:47 AM, Steve Clark <sclark at netwolves.com>
wrote:
> On 06/25/2015 06:44 PM, Chris Murphy wrote:
>> I did a bunch of testing of Raw, qcow2, and LV backed VM storage circa
>> Fedora 19/20 and found very little difference. What mattered most was
>> the (libvirt) cache setting, accessible by virsh edit the xml config
>> or virt-manager through the GUI. There have been a lot of
>
> Which setting did you find most effective?
In terms of performance, unsafe. Overall, it's hard to say because
it's so configuration and use case specific. In my case, I do lots of
Fedora installs, and Btrfs related testing, and the data I care about
is safeguarded other ways. So I care mainly about VM performance, and
therefore use unsafe. I haven't yet lost data in a way attributable to
that setting (top on the list is user error, overwhelmingly, haha).

You might find this useful:
https://rwmj.wordpress.com/2013/09/02/new-in-libguestfs-allow-cache-mode-to-be-selected/

And this:
https://github.com/libguestfs/libguestfs/commit/749e947bb0103f19feda0f29b6cbbf3cbfa350da

Of particular annoyance to me in Virt-Manager is the prolific use of
the word "Default" which doesn't tell you diddly. The problem is
Virt-Manager supports different hypervisors and all of them can have
different defaults which don't necessarily propagate through to
libvirt and I'm not sure that libvirt is even able to be aware of all
of them. So we get this useless placeholder called default. Default is
not good just because you don't know what it is. It's not necessarily
true that default translates into what's recommended  - that may be
true, but it may also not be ideal for your use case.



-- 
Chris Murphy