On Mon, Mar 02, 2015 at 05:38:11PM +0400, Vasiliy Tolstov wrote: > Hello. I'm interesting in implementing overlayfs support to lxc libvirt driver. > As i see i simply can utilize filesystem type='template' for this usage. The semantics of the 'template' type are that the virt driver unpacks a pre-built named template image and uses that for the guest filesystem. I don't think we should try to twist that into use for overlayfs. In any case, all of the existing mount types could conceivably benefit from the use of an overlay. > In case os template fs i need to mount with lowerdir > /var/lib/libvirt/filesystems/template to > /var/lib/libvirt/filesystems/name > > But i have problem: overlayfs fs need upperdir that store differences > and mountpoint that used by clients. In case of libvirt usage - > upperdir need to be places in /var/lib/libvirt/filesystems, but where > i can put mountpoint dir ? /var/run/libvirt or in /tmp/libvirt-XXXXX ? > > Also what is the preferred way to integrate overlayfs support to > libvirt? I can addd mount type to filesystem type='mount' or use (like > now) template type. What is the preferred way? > Thanks Conceptually creating a target for the overlay is easy, the difficult question is how do we expect apps to actually manage the overlays once created. In particular at which point do they get deleted. I don't think we would want delete them at container shutdown, at least not for persistent containers - it could work for transient containers. At the same time we would definitely not want to do it during undefine either since that is really intended to only remove the config. Deleting the data could take a non-negligble amount of time to complete if the container had made lots of changes to its filesystem vs the backing store. So this all suggests and out of band mechanism for overlayfs management. So It feels like we might need to integrate the overlayfs support into the storage pools implementation instead. eg in the filesystem storage pool driver, we could allow for the creation and deletion of overlays for directories. Then the LXC driver would not need any changes at all -it would simply point an a directory that's an overlay and use the existing type=mount support. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list