On Sat, 19 Sep 2015 12:13:29 AM Austin S Hemmelgarn wrote: > The other option (which for some reason I almost never see anyone > suggest), is to expose 2 disks to the guest (ideally stored on different > filesystems), and do BTRFS raid1 on top of that. In general, this is > what I do (except I use LVM for the storage back-end instead of a > filesystem) when I have data integrity requirements in the guest. On > the other hand of course, most of my VM's are trivial for me to > recreate, so I don't often need this and just use DM-RAID via LVm.
I used to do that. But it was very fiddly and snapshotting the virtual machine images required making a snapshot of half a RAID-1 array via LVM (or snapshotting both when the virtual machine wasn't running). Now I just have a single big BTRFS RAID-1 filesystem and use regular files for the virtual machine images with the Ext3 filesystem. On Sun, 20 Sep 2015 11:26:26 AM Jim Salter wrote: > Performance will be fantastic... except when it's completely abysmal. > When I tried it, I also ended up with a completely borked (btrfs-raid1) > filesystem that would only mount read-only and read at hideously reduced > speeds after about a year of usage in a small office environment. Did > not make me happy. I've found performance to be acceptable, not great (you can't expect great performance from such things) but good enough for lightly loaded servers and test systems. I even ran a training session on BTRFS and ZFS filesystems with the images stored on a BTRFS RAID-1 (of 15,000rpm SAS disks). When more than 3 students ran a scrub at the same time performance dropped but it was mostly usable and there were no complaints. Admittedly that server hit a BTRFS bug and needed "reboot -nf" half way through, but I don't think that was a BTRFS virtual machine issue, rather it was a more general BTRFS under load issue. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
