Benefits of ZFS which you will still realize in this situation: checksumming and repairing of data given adequate redundancy. compression. dedup. pooled storage. slog. l2arc. snapshots. zfs send/receive for backups/disaster recovery preparation.
If your guest crashes, yes, you may still have to fsck. Much like how ZFS can't make sure a database doesn't have bad data in a table, it can't fix logical filesystem errors in a virtual disk file. It can make sure that what has been written is consistent and can tell the hypervisor layer when that data has been written safely. I'm not sure which other benefits you have in mind. Practically, we find that VMWare ESX hosts mounting ZFS volumes over NFS works quite well with few surprises. --Doug On Thu, Mar 13, 2014 at 3:58 PM, Francois Gaudreault < [email protected]> wrote: > 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 > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
