[Users] SIMFS users

[Volker Janzen]

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 <kir at 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 at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>