Hi, I'm using one LVM logical volumes per container with simfs on one setup. Is it possible to do something like that with ploop, too?
Regards Volker > Am 21.07.2015 um 23:11 schrieb Kir Kolyshkin <k...@openvz.org>: > > > >> On 07/21/2015 08:51 AM, Michael Stauber wrote: >> Hi Scott, >> >>> Ummm, you can still access the files inside of ploop-based container >>> when it isn't running... simply by mounting it. Is there an issue >>> with that? >> Granted: It's probably more of a psychological or philosophical issue >> than a technical one. Filesystem on a filesystem. That adds a level of >> complexity and another potential point of failure. Yes, it has benefits. >> But ease of access to anything while using simfs often seems to >> outweight that. Even if people don't use it for that reason: It adds >> some peace of mind that they could - if they wanted to. Potential quota >> and inode issues alone won't deter them from using simfs that way. > > The biggest problem with simfs appears to be security. We have recently > found a few bugs (not in simfs per se, but in the kernel in general, i.e. > these > are not our bugs for the most part) that can be exploited to escape > the simfs and let container access the host file system. One single bug > like that should have everyone who is at least slightly concerned about > security to move to ploop. And there were a few :( > > Other "why not simfs" considerations are listed at > http://openvz.org/Ploop/Why#Before_ploop > Of those, the biggest issue is common filesystem journal. A single container > can issue a lot > of operations (like file truncate) leading to lots of journal updates, > essentially blocking the rest > of containers to do anything what involves journal. This is bad as it breaks > inter-container > isolation to some degree. > >> Think of existing architectures where someone fiddled in some custom >> backup scripts to do partial or complete VPS backups. > > Well, this is just plain wrong wrong. The correct way to access a VPS > filesystem (doesn't matter > if this is ploop or simfs or something else) is: > > vzctl mount $CTID > cd /vz/root/$CTID # to prevent unmount say if a container is stopped > # work with data at /vz/root/$CTID > vzctl umount $CTID > >> Sure, it's >> possible with ploop, too. But it would require tampering with something >> that ain't broken to begin with. > > I would say it is broken even for simfs. For example, if you change something > in /vz/private/$CTID, such as add, delete, or modify any files, these changes > will not be reflected in vzquota, leading to wrong disk space usage, and the > limits > won't work as they should. > > You would argue that accessing /vz/private/$CTID read-only is OK from the > perspective > of vzquota -- I'd say it is just a wrong assumption that a container files > can be accessed > from /vz/private/$CTID -- it just happens to work with current simfs and > OpenVZ. > >> Don't get me wrong: I like ploop and have no issue with it. Other >> virtualization solutions (containerized or not) also usually have their >> own filesystem for VMs or containers and direct access to that from the >> HN also needs some crutches or work arounds. Still: I'd be fighting an >> uphill battle if I'd were to introduce it as default for my users. >> Somehow ploop doesn't provide a "killer-feature" that would help me in >> convincing those that either don't know ploop yet, or haven't used it >> yet. But maybe someone has some talking points that would help me to win >> some hearts and minds there? > > http://openvz.org/Ploop/Why > > In addition to everything I said earlier, worth noting are ploop snapshots > (and easy consistent backups!), NFS support, and efficient live migration > using ploop copy. > >> >> To get back to the original question that Sergey asked: He maybe asked >> because they're considering to eventually drop simfs support. Because >> that's how I'd test the waters if I were to retire some legacy features >> from my own projects. To that I humbly say: Please don't. We like that >> ugly duckling and would like to keep it. Alternatively: Give us a really >> good reason (or a "killer-feature") that makes it a "must have" item. > > _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users