So bottomline, unless the "enterprise grade" (vmware/xen/etc) hypervisor can make the guest to talk straight to the ZFS pool/volume, then we kinda loose much of the benefits of ZFS, right? ZFS becomes a large RAID.. kinda. Most of these hypervisors will talk to an NFS head or iSCSI, so the VM is logically a file.
FG On Mar 13, 2014 3:13 PM, "Robert Mustacchi" <[email protected]> wrote: > On 3/13/14 10:32 , Francois Gaudreault wrote: > > Hello ZFS people :) > > > > As a cloud provider, we are trying to see how ZFS would help us to > > optimizing how we store VM data. However, we have some blind spots, and > > we would like to get some answers :) Hopefully, I am at the right place > > for that. Yes I could spend some days to search on the web, and yes the > > answer is probably there somewhere, but asking to experts is much faster > :P > > > > Basically, let's say we have a linux VM running on EXT or XFS as the > > local filesystem, how is XFS/EXT consistency helped by ZFS features? > > (i.e Is it true to say fsck would be useless if we use ZFS?) And the > > other question would be, how do we make sure we get consistent snapshots > > when using c-o-w? > > I'm assuming you're talking about hardware virtualization here. If > that's the case, ZFS can help, but it requires your guest to be correct > in the first place and depends on the nature of your emulation. Consider > standard HVM where you're modeling a disk and a disk cache. You are not > at the mercy of your guest correctly sending cache flush commands for > correctness so that everything gets on disk. Historically not many file > systems did this correctly, maybe they're doing better. If your guest > and hypervisor don't do this correctly, then it doesn't matter what FS > you have. So whether or not you need fsck depends on whether or not you > need it on real hardware. > > Your snapshots will always be consistent from a ZFS perspective, the > question is whether they represent the desired state from your HVM > guest. To do this you need to coordinate with your guest and hypervisor > to quiesce all I/O and ensure that any disk cache has been flushed. If > it hasn't, then when you restore, your guest may need to do anything > from journal replay, to fsck, depending on how the file system is > implemented. At Joyent, we don't emulate a disk cache and instead let > every write be synchronous and use a slog to absorb that. > > In general, I find the other features of ZFS to be more useful here. eg. > being able to turn on compression. You can also manage things by > creating base images which are ZFS datasets and every subsequent guest > is a clone of this. Pooled storage also helps immensely. ZFS's built in > consistency is good, as that way you know that the host hasn't corrupted > the guest data, but of course, that doesn't help ensure that the guest > hasn't corrupted itself. Incremental snapshots and send+recv are a > reasonable way to do a migration. > > Robert > _______________________________________________ > developer mailing list > [email protected] > http://lists.open-zfs.org/mailman/listinfo/developer >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
