2015-03-02 16:59 GMT+03:00 Daniel P. Berrange <berrange@xxxxxxxxxx>: > 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. So as i understand i need to add overlayfs like virStorageBackendFileSystem for example virStorageBackendOvlFileSystem but i don't understand how can this pool be used in case of many containers. May be i misunderstand something? -- Vasiliy Tolstov, e-mail: v.tolstov@xxxxxxxxx jabber: vase@xxxxxxxxx -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list