With ZFS you may not only do "file system" stuff but ZFS may also provide raw block devices ("zvol") which benefit from ZFS space accounting, snapshotting, checksumming, etc. A purpose of these is to use these zvols and exporting them via iSCSI or give them to applications which can store data on them. One application for this I'm using s VirtualBox and as I always forget the exact commands needed to create a zvol and making it available to VBox I decided to write it down.
Reasons for me for using zvols instead of regular VBox disks are that I can easily snapshot them (every 15 minutes a snapshot ...) individually and can easily clone them (around one second and barely any disk space needed to get a clone of a VM to do some experimental stuff...) and incremental backups using snapshots and zfs send. That said there's at least one - possibly - negative factor: A regular virtual disk file can be shared with other people and other operating systems, a zvol has to be dumped into a regular vmdk first.
Anyways here are the steps needed:
# zfs create -V 10G tank/some_name
# chown johannes /dev/zvol/rdsk/tank/some_name
# VBoxManage internalcommands createrawvmdk \
-filename /home/johannes/VBoxdisks/some_name.vmdk \
-rawdisk /dev/zvol/rdsk/tank/some_name
# VBoxManage registerimage disk /home/johannes/VBoxdisks/some_name.vmdk
So first we create the zvol with a size of 10G. This won't be allocated but everybody asking for the size of the device will get this information back and this is the maximum size that will be used - as one can use compression and dedup there this often might be way less usage. Then, as I'm running VBox under my user account, I give my user all the rights needed by making the regular user the owner. The third step creates a vmdk file pointing to the raw device location which is then registered with VirtualBox so a VM can be configured for using it.
Works nicely.
Wednesday, July 28. 2010 at 21:26 (Reply)
You get all the benefits: snapshot, rollback, cloning, etc.
You also get to use the standard VirtualBox disk file (or vmdk).
Cheers,
Charles
Thursday, July 29. 2010 at 00:51 (Reply)
Well, then I'd have to create one ZFS filesystem per virtual disk to have it as nice (Ijsut want to rollback one disk etc.) and I don't move VMs that much around, so for me there is no issue if I don't have these files - for others this might not be the case, though.
While there is one issue with your approach: If you clone a virtualBox disk file this file includes a seria number which has to be unique per VBox installation. Constantin Gonzalez has a blog posting (Search for it
Thursday, July 29. 2010 at 09:21 (Reply)
How do you manage incremental backups?
Do you zsend on LTOs?
Do you just backup the row zfs?
How would you manage single file recovery in this case (when it's not in the living zfs snaphots)?
Thursday, July 29. 2010 at 16:59 (Reply)
Most of my machines are development/test machines where my typical usage pattern is to have a "base" VM installed which I then clone, do some work and then destroy. So I only need backups for specific states (between OS updates etc.) for this usage pattern it works nicely to backup using zfs send/recv. Most actual data I keep in a shared folder on the host system, which has its own backup needs.
If you keep actual data inside your VMs you most likely need a more sophisticated strategy.