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.
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.
Am 26.06.2015 um 12:47 schrieb Steve Clark sclark@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@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-...
And this: https://github.com/libguestfs/libguestfs/commit/749e947bb0103f19feda0f29b6cb...
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 -
Leon Fauster -
Steve Clark