On 22.07.2015 8:39, Kir Kolyshkin wrote:
1) currently even suspend/resume not work reliable:
https://bugzilla.openvz.org/show_bug.cgi?id=2470
- I can't suspend and resume containers without bugs.
and as result - I also can't use it for live migration.
Valid point, we need to figure it out.
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,
Greetings,
- Original Message -
Compare two situations:
1) Live migration not used at all
2) Live migration used and containers migrated between HN
In which situation possibility to obtain kernel panic is higher?
If you say possibility are equals this means
what OpenVZ live
FWIW, I regularly did live migrations of e.g. smtp servers, mailguard nodes
etc for years while working at Toyota, and never saw any kernel panic, and
never heard of anyone else having an issue. I'm not saying it's impossible,
but it seems you must have some sort of strange corner case there.
So I was taking a look at the iostats file for the below mentioned vm and I
have a question. On the documentation page you list 10 columns, however the
iostat file has 12? Are there two undocumented ones?
root [3.80 ] ~ #cat /proc/bc//iostat
flush . 0 0 0 0 0 1717 13736 0 0
fuse .
Den 2015-07-22 15:23, Michael Stauber skrev:
Hi Johan,
I guess containers could be converted, but can the bind mounts be done
without simfs in a simple way as well?
Regardless if you use simfs or ploop, a VPS or a real machine: For
things like that I find fuse-sshfs quite useful. With that
Greetings,
- Original Message -
and also ext4 over ploop over ext4 wasting disk space as overhead.
That is the case for all disk-file-as-disk-image containers and not unique to
ploop. You said if you can't use OpenVZ and ZFS together (in the future maybe)
then you'd switch to KVM...
On 22.07.2015 21:02, Scott Dowdle wrote:
Compare two situations:
1) Live migration not used at all
2) Live migration used and containers migrated between HN
In which situation possibility to obtain kernel panic is higher?
If you say possibility are equals this means
what OpenVZ live
On 22.07.2015 5:56, Scott Dowdle wrote:
I've read the recipes.
Some say you have to dedicate 1GB of RAM for every TB of storage.
dedicate 1GB of RAM for every TB of storage
need only if deduplication is turned on in ZFS.
But deduplication is not recommended to enable - it uses
lot of memory
On 07/22/2015 01:08 PM, Gena Makhomed wrote:
My experience with ploop:
DISKSPACE limited to 256 GiB, real data used inside container
was near 40-50% of limit 256 GiB, but ploop image is lot bigger,
it use near 256 GiB of space at hardware node. Overhead ~ 50-60%
I found workaround for
and if ZFS means it can't be used... that is just another reason (for me)
not to use ZFS.
It can be used with ZFS if both hosts have ZFS and containers in zvol, imho.
But yes - it require vzmigrate version with support copy zvol snapshots to
another host.
2015-07-22 11:03 GMT+03:00 Сергей
On 22/07/15 00:11, users-boun...@openvz.org on behalf of Kir Kolyshkin
users-boun...@openvz.org on behalf of k...@openvz.org wrote:
Other why not simfs considerations are listed at
http://openvz.org/Ploop/Why#Before_ploop
That¹s good, but there is an issue with using ploops. If you want to
We are using simfs because ploop do not support 16+ TB partitions. Please
do not drop simfs support.
2015-07-22 8:47 GMT+03:00 Kir Kolyshkin k...@openvz.org:
On 07/21/2015 07:56 PM, Scott Dowdle wrote:
Greetings,
- Original Message -
ZFS is really The Last Word in File Systems,
Hi Johan,
I guess containers could be converted, but can the bind mounts be done
without simfs in a simple way as well?
Regardless if you use simfs or ploop, a VPS or a real machine: For
things like that I find fuse-sshfs quite useful. With that you can mount
a remote directory via SSH to a
On 07/22/2015 01:21 AM, Pavel Gashev wrote:
On 22/07/15 00:11, users-boun...@openvz.org on behalf of Kir Kolyshkin
users-boun...@openvz.org on behalf of k...@openvz.org wrote:
Other why not simfs considerations are listed at
http://openvz.org/Ploop/Why#Before_ploop
That¹s good, but there is
Den 2015-07-21 16:48, Scott Dowdle skrev:
Greetings,
- Original Message -
If our users have to choose between no more inode issues or having
direct access to all VPS files and folders from the HN, then ploop
will probably always get the short end of the stick.
Ummm, you can still
On 07/22/2015 11:31 AM, Gena Makhomed wrote:
my point is there will always be bugs... but to point at a bug report
and give up saying that it isn't stable because of bug report x... or
that some people have had panics at some point in history... well,
that isn't very reflective of the overall
On 07/22/2015 10:08 AM, Gena Makhomed wrote:
On 22.07.2015 8:39, Kir Kolyshkin wrote:
1) currently even suspend/resume not work reliable:
https://bugzilla.openvz.org/show_bug.cgi?id=2470
- I can't suspend and resume containers without bugs.
and as result - I also can't use it for live
On 07/22/2015 11:31 AM, Gena Makhomed wrote:
Regarding OpenVZ checkpoint / restore and live migration... it has
worked well for me since it was originally released in 2007 (or was
it 2008?). While I've had a few kernel panics in the almost 10 years
I've been using OpenVZ (starting with the
On 22.07.2015 21:58, Scott Dowdle wrote:
ext4 over ploop over ext4 wasting disk space as overhead.
That is the case for all disk-file-as-disk-image containers and not
unique to ploop. You said if you can't use OpenVZ and ZFS together
(in the future maybe) then you'd switch to KVM... at
Greetings,
- Original Message -
In case of ploop - free space inside ploop can't be used any more,
and from hardware node point of view - this disk space is wasted,
even in case when it unused and marked as free inside ploop image.
That is not entirely true. While I haven't really
21 matches
Mail list logo
