The patch below shows a possible approach to adding ZFS root support
to release(7). It's a draft, completely untested; I'd like to hear
some feedback first, in particular to the approach itself. For example,
do we want to have separate CloudWare conf files, eg tools/ec2-zfs in
addition to tools/ec2.conf? Thanks!
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 28880 Build 26882: arc lint + arc unit
Event Timeline
Comment Actions
In general, I have reservations against zfs-based virtual machine images.
My concern is ZFS can expose the path of the mount point from the build machine, which in effect eliminates build reproducibility.
There may be other sharp edges in producing ZFS-based virtual machine images that I have not yet realized and/or thought of.
| release/tools/zfs.conf | ||
|---|---|---|
| 21 | The /var/mail directory needs atime=on in order to alert of new local mail. | |
Comment Actions
Those could be fixed (perhaps by post-processing the ZFS file system image), but you're right that there may well be other sources of non-reproducibility in online creation of a ZFS disk image. I wonder how feasible it would be to have ZFS support in makefs.
In any case I think it's definitely sensible for us to have tooling in the tree for creating ZFS based VM images; whether we could/should provide those as official images from re@ is a separate matter.
Comment Actions
I don't think the paths will be a problem for reproducibility. You can use temp mounts (mount -t zfs pool/dataset /mnt/whatever) or altroot (create or import the pool with an altroot=/mnt or some other path, and it will prefix all mountpoints with that path).
The issue for reproducibility will be that ZFS generates unique GUIDs for the pool, the disks, each dataset, each snapshot, etc. Might also need to fiddle with a few timestamps that get embedded in the pool (zpool history)
i don't know how practical it is to actually achieve reproducible ZFS images.
However, I think there is a lot of value in having official ZFS images.
| release/tools/zfs.conf | ||
|---|---|---|
| 70 | Should this be in a file shared by here and usr.sbin/bsdinstall/scripts/zfsboot (and perhaps some other defaults)? Otherwise it'll be far too easy for the VM images to get out of sync with the installer config. | |
| 163–170 | This should be more like vmimage.subr (maybe even by integrating with it?) so you get an ESP and support aarch64. | |
Comment Actions
I think this is OBE with recent changes to add ZFS and UFS support simultaneously for virtual machine image builds.