From OpenVZ Virtuozzo Containers Wiki
<translate>
Comparison tables
Solidity in front of failures and security
| Feature
|
OVZ Ploop
|
OVZ SimFS (ext4)
|
LVM (ext4)
|
ZFS
|
| I/O isolation
|
Good
|
Bad: Some bug could be exploited to escape CT and access HN file system [1] [2]
|
Good
|
Good
|
| Reliability
|
Low: big amount of files produce ext4 corruption so often
|
Medium: fsck, power loss and HW Raid without cache can kill whole data
|
High: LVM metadata can be corrupted completely
|
Excellent: no write hole, checksumming and COW
|
| Filesystem over filesystem
|
Yes
|
No
|
No
|
?
|
| Effect of HN filesystem corruption at /vz
|
No effect
|
Same FS
|
?
|
?
|
| Maturity in O/VZ
|
Since 2012
|
Since ~2005
|
Since 1998
|
Since 2014
|
Performance and design features
| Feature
|
OVZ Ploop
|
OVZ SimFS (ext4)
|
LVM (ext4)
|
ZFS (~simfs)
|
| Maximum container volume space
|
4 TiB [3]
|
1 EiB [4]
|
?
|
256 ZiB
|
| Wasted space due to architecture
|
up to 20%
|
No
|
up to 20%
|
?
|
| Disk i/o speed
|
Fast in any case
|
Very fast with small amount of containers
|
Fast in any case
|
Fast in any case
|
| Disk space overcommit (provide more space for containers than available on server now)
|
Yes
|
Yes
|
No
|
Yes
|
| Different containers may use file systems of different types and properties
|
Yes
|
No
|
Yes
|
No
|
| Second level quotes in Linux (inside container)
|
Yes
|
Yes
|
Yes
|
Not implemented
|
| Potential support for QCOW2 and other image formats
|
Yes
|
No
|
No
|
No
|
| Incremental backup support on filesystem level
|
Yes, through snapshots
|
No
|
No
|
Yes
|
Administrator operations
| Feature
|
OVZ Ploop
|
OVZ SimFS (ext4)
|
LVM (ext4)
|
ZFS (~simfs)
|
| vzctl integration
|
Complete
|
Complete
|
No, many manual operations
|
No, some manual operations
|
| External compaction for container volumes
|
Needed for saving HN space
|
No
|
Not available
|
Not required
|
| Access to private area from host
|
Yes
|
Yes
|
?
|
?
|
| Live backup
|
Easy, fast and consistent[5] [6]
|
Easy, slow, and sometimes inconsistent in case some application depends on inode IDs
|
Fast
|
Fast theoretically
|
| Snapshot support
|
Yes[7]
|
No theoretically, because of much/small files to be copied
|
Yes
|
Yes
|
| Live migration
|
Reliable and fast
|
Not reliable and slow, if some application depends on inode IDs
|
Not implemented
|
Fast theoretically
|
| Continue failed CT migration
|
Yes, in vzctl from OpenVZ -stable
|
Yes, option "--keep-dst"
|
Not implemented
|
?
|
</translate>
This article is a stub. You can help OpenVZ Wiki by expanding it. 