Stéphane Graber
Stéphane Graber
Alternatively a regular bridge combined with specific containers getting an external address through `ipv4.routes` could work too, but you'll need the addresses or subnets to be routed to the host...
So should we go with this idea, the obvious restrictions would be: - A container will need a fixed `ipv4.address` in order to use `ipv4.nat.address` - Container to container communication...
No real reason not to support it, though it'd certainly not be anywhere near the feature set of zfs/btrfs, at best I'd expect it to be somewhat similar to LVM.
Yeah, I suspect we can do quite a few of the things we need by using qcow2 overlays, the obvious downside being that we'd need to keep the source image...
`lxc image import` for VMs takes a tarball as first argument (for metadata) and a QCOW2 as second argument for the rootfs, so we effectively already support that.
It's a bit tricky from a security point of view and will need some API changes to allow it. The fact that images can be tied to profiles in their...
So we've made some progress on this thanks to the VM support. We have logic to create, snapshot, ... zvols on zfs. However this is currently only available for VM...
That's not really practical though as most of those are superblock options and so cannot be handled on a per mount basis. The main exception here would be ZFS. For...
`block.mount_options` does exactly this on LVM and Ceph. btrfs and dir cannot do it per volume. This leaves us with zfs which I guess could get a zfs.properties with a...