2015-03-02 16:59 GMT+03:00 Daniel P. Berrange <berrange(a)redhat.com>:
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(a)selfip.ru
jabber: vase(a)selfip.ru