Re: [Users] SSD trim support over a LUKS layer

[spameden]

No. It's impossible to use OpenVZ 6 with kernel 4.x, unless you put lots of
effort to port their patches over the fresh kernel.

The latest OpenVZ 6 kernel is 2.6.32-openvz-042stab136.1-amd64 and there is
an issue with discard (it doesn't work).

The discard issue has been fixed in 3.1-mainline kernel I think, you can
look over newish RHEL kernel and try to port those changes to the old
legacy OpenVZ 6 kernel.

Regarding 4.x kernel:
I'm using Proxmox with 4.x kernel (there is no OpenVZ) - only LXC
containers and KVM - and there is no issue with discards at all.
and what I also meant is: that you can easily migrate your existing OpenVZ
containers to the Proxmox.

Proxmox is based on latest Debian Stretch and specifically designed as a
distro for contrainers.
It has GUI, networking support (including openvswitch and other), KVM/LXC
support and many other things (e.g. ceph/glusterfs support).

Though, reading you again you've mentioned that you need a specific simfs
quota in containers:
most likely that would be impossible for unprivileged containers with
directory storage (simfs analogue), althrough you could use qcow2 or
LVM-based storage for containers.


вс, 28 апр. 2019 г. в 09:47, Narcis Garcia :

> El 27/4/19 a les 22:15, spameden ha escrit:
> >
> > сб, 27 апр. 2019 г. в 20:16, Narcis Garcia  > <mailto:informat...@actiu.net>>:
> >
> > I responded about OpenVZ/6 vs LXC, and Proxmox doesn't solve the
> Discard
> >
> >
> > What do you mean it doesn't solve the issue with discard? It does.
> >
> > Discard is perfectly working on Proxmox kernel 4.15.18-12-pve or even on
> > 4.13 kernel on DM-Crypt/LUKS setup.
> >
> > I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm
> > talking about.
>
> Are you really using OpenVZ 6 with Linux kernel 4.x?
> Did you see any difficult with Discard when using other context with
> Linux 4.x ?
> ___
> 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

Re: [Users] SSD trim support over a LUKS layer

[spameden]

сб, 27 апр. 2019 г. в 20:16, Narcis Garcia :

> I responded about OpenVZ/6 vs LXC, and Proxmox doesn't solve the Discard
>

What do you mean it doesn't solve the issue with discard? It does.

Discard is perfectly working on Proxmox kernel 4.15.18-12-pve or even on
4.13 kernel on DM-Crypt/LUKS setup.

I'm using on all my servers DM-Crypt/LUKS + LVM so I know what I'm talking
about.


> issue for OpenVZ/6 with a LUKS layer.
>
> With any of Devuan 1, 2, Debian 8, 9 kernels, Discard works fine with
> LUKS layer (with or without LXC), and Proxmox doesn't help in this.
>
>
> El 27/4/19 a les 16:39, spameden ha escrit:
> > Furthermore there might be issues using old legacy OpenVZ6 kernel on
> > modern hardware, e.g. NVMe or any newer NIC cards.
> >
> > Seeing as you've been using Debian as well as me for quite some time I'd
> > recommend - https://proxmox.com
> >
> > In proxmox you can use unprivileged LXC containers (for security) as
> > well as containers with directory storage though they don't support
> > quotas (but you save on precious nvme disk storage).
> >
> > There is also fancy webui, but I don't use it, mainly sticking to the
> > console pct tool and template's system.
> >
> > There is a bit hassle regarding using external IPs in the containers,
> > but it's possible via certain workaround with iptables and routing.
> >
> > Proxmox also works natively with latest Debian Stretch (with systemd)
> > and it's using recent kernel, e.g.:
> >
> > # uname -r
> > 4.15.18-12-pve
> >
> > and yes discards work just fine on proxmox:
> >
> > # dmsetup table|grep discards
> > ***: 0 123 crypt aes-xts-plain64
> >  0 9:1
> > 4096 1 allow_discards
> >
> > Migration from OpenVZ6 is also very straightforward to Proxmox: in most
> > cases containers just do work (if you've been using simfs before) and
> > not requiring any modifications.
> >
> >
> >
> > сб, 27 апр. 2019 г. в 17:28, CoolCold  > <mailto:coolthec...@gmail.com>>:
> >
> > I believe to have fixes and backports like this in to legacy version
> > of product will not happen, and you should consider upgrading.
> > Personally, I've upgraded to lxc.. it's quite primitive comparing to
> > ovz 6, but it's enough for my needs.
> >
> > On Sat, Apr 27, 2019, 17:49 spameden  > <mailto:spame...@gmail.com>> wrote:
> >
> > Yes, it's an issue in kernel.
> >
> > As dm-crypt/luks layer isn't passing TRIM to the underlying
> device.
> >
> > /boot is not encrypted that's why it works for you.
> >
> > сб, 27 апр. 2019 г. в 11:11, Narcis Garcia
> > mailto:informat...@actiu.net>>:
> >
> > See in the case that /dev/sda1 (Directly mounted as Ext4 on
> > /boot) works with Trim/Discard.
> > It's the sda2_crypt (layer over sda2) that is not detected
> > to be trimmable. Devuan's stock kernel does.
> >
> > CentOS issue #6548 may not be this same bug; I've tested now
> > with CentOS 6.8 with a similar (but not same) result*:*
> >
> > $ lsb_release -d
> > Description:CentOS release 6.8 (Final)
> >
> > $ uname -a
> > Linux localhost.localdomain 2.6.32-642.el6.x86_64 #1 SMP Tue
> > May 10 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> >
> > $ lsblk --discard /dev/sda
> > NAME
> > DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
> > sda
> > 0  512B   2G 0
> > ├─sda1
> > 0  512B   2G 0
> > └─sda2
> > 0  512B   2G 0
> >   └─luks-f691f48b-8556-487d-ac64-50daa99ed4c9 (dm-0)
> > 0  512B   2G 0
> >
> >     $ cat /etc/crypttab
> > luks-f691f48b-8556-487d-ac64-50daa99ed4c9
> > UUID=f691f48b-8556-487d-ac64-50daa99ed4c9 none luks,discard
> >
> > $ mount | grep -e discard
> > /dev/mapper/luks-f691f48b-8556-487d-ac64-50daa99ed4c9 on /
> > type ext4 (rw,discard)
> > /dev/sda1 on /boot type ext4 (rw,discard)
> >
> > $ sudo fstrim /boot
> >  

Re: [Users] SSD trim support over a LUKS layer

[spameden]

Furthermore there might be issues using old legacy OpenVZ6 kernel on modern
hardware, e.g. NVMe or any newer NIC cards.

Seeing as you've been using Debian as well as me for quite some time I'd
recommend - https://proxmox.com

In proxmox you can use unprivileged LXC containers (for security) as well
as containers with directory storage though they don't support quotas (but
you save on precious nvme disk storage).

There is also fancy webui, but I don't use it, mainly sticking to the
console pct tool and template's system.

There is a bit hassle regarding using external IPs in the containers, but
it's possible via certain workaround with iptables and routing.

Proxmox also works natively with latest Debian Stretch (with systemd) and
it's using recent kernel, e.g.:

# uname -r
4.15.18-12-pve

and yes discards work just fine on proxmox:

# dmsetup table|grep discards
***: 0 123 crypt aes-xts-plain64
 0 9:1 4096
1 allow_discards

Migration from OpenVZ6 is also very straightforward to Proxmox: in most
cases containers just do work (if you've been using simfs before) and not
requiring any modifications.



сб, 27 апр. 2019 г. в 17:28, CoolCold :

> I believe to have fixes and backports like this in to legacy version of
> product will not happen, and you should consider upgrading. Personally,
> I've upgraded to lxc.. it's quite primitive comparing to ovz 6, but it's
> enough for my needs.
>
> On Sat, Apr 27, 2019, 17:49 spameden  wrote:
>
>> Yes, it's an issue in kernel.
>>
>> As dm-crypt/luks layer isn't passing TRIM to the underlying device.
>>
>> /boot is not encrypted that's why it works for you.
>>
>> сб, 27 апр. 2019 г. в 11:11, Narcis Garcia :
>>
>>> See in the case that /dev/sda1 (Directly mounted as Ext4 on /boot) works
>>> with Trim/Discard.
>>> It's the sda2_crypt (layer over sda2) that is not detected to be
>>> trimmable. Devuan's stock kernel does.
>>>
>>> CentOS issue #6548 may not be this same bug; I've tested now with CentOS
>>> 6.8 with a similar (but not same) result*:*
>>>
>>> $ lsb_release -d
>>> Description:CentOS release 6.8 (Final)
>>>
>>> $ uname -a
>>> Linux localhost.localdomain 2.6.32-642.el6.x86_64 #1 SMP Tue May 10
>>> 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> $ lsblk --discard /dev/sda
>>> NAME DISC-ALN DISC-GRAN
>>> DISC-MAX DISC-ZERO
>>> sda 0
>>> 512B   2G 0
>>> ├─sda1  0
>>> 512B   2G 0
>>> └─sda2  0
>>> 512B   2G 0
>>>   └─luks-f691f48b-8556-487d-ac64-50daa99ed4c9 (dm-0)0
>>> 512B   2G 0
>>>
>>> $ cat /etc/crypttab
>>> luks-f691f48b-8556-487d-ac64-50daa99ed4c9
>>> UUID=f691f48b-8556-487d-ac64-50daa99ed4c9 none luks,discard
>>>
>>> $ mount | grep -e discard
>>> /dev/mapper/luks-f691f48b-8556-487d-ac64-50daa99ed4c9 on / type ext4
>>> (rw,discard)
>>> /dev/sda1 on /boot type ext4 (rw,discard)
>>>
>>> $ sudo fstrim /boot
>>> # (same result as Devuan/1 and OpenVZ/6 kernel: success)
>>>
>>> $ sudo fstrim /
>>> fstrim: /: FITRIM ioctl failed: Operation not supported
>>>
>>>
>>> El 26/4/19 a les 21:36, spameden ha escrit:
>>>
>>> Hi.
>>>
>>> I've asked this question years ago (in 2013):
>>> https://lists.openvz.org/pipermail/users/2013-August/005250.html
>>>
>>> Let me know if it helps, but this bug should have been fixed in CentOS
>>> and RHEL at least: https://bugs.centos.org/view.php?id=6548
>>>
>>> Maybe OpenVZ maintainers didn't pick up this fix in the openvz6 legacy
>>> kernel?
>>>
>>> Thanks.
>>>
>>> ср, 10 апр. 2019 г. в 10:45, Narcis Garcia :
>>>
>>>> Does anybody know how can I solve this?
>>>>
>>>> $ lsb_release -d
>>>> Description:Devuan GNU/Linux 1.0 (jessie)
>>>>
>>>> $ uname -a
>>>> Linux bell1 2.6.32-openvz-042stab134.8-amd64 #1 SMP Fri Dec 7 17:18:40
>>>> MSK 2018 x86_64 GNU/Linux
>>>>
>>>> $ lsblk --discard /dev/sda
>>>> NAME   DI

Re: [Users] SSD trim support over a LUKS layer

[spameden]

Yes, it's an issue in kernel.

As dm-crypt/luks layer isn't passing TRIM to the underlying device.

/boot is not encrypted that's why it works for you.

сб, 27 апр. 2019 г. в 11:11, Narcis Garcia :

> See in the case that /dev/sda1 (Directly mounted as Ext4 on /boot) works
> with Trim/Discard.
> It's the sda2_crypt (layer over sda2) that is not detected to be
> trimmable. Devuan's stock kernel does.
>
> CentOS issue #6548 may not be this same bug; I've tested now with CentOS
> 6.8 with a similar (but not same) result*:*
>
> $ lsb_release -d
> Description:CentOS release 6.8 (Final)
>
> $ uname -a
> Linux localhost.localdomain 2.6.32-642.el6.x86_64 #1 SMP Tue May 10
> 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> $ lsblk --discard /dev/sda
> NAME DISC-ALN DISC-GRAN
> DISC-MAX DISC-ZERO
> sda 0
> 512B   2G 0
> ├─sda1  0
> 512B   2G 0
> └─sda2  0
> 512B   2G 0
>   └─luks-f691f48b-8556-487d-ac64-50daa99ed4c9 (dm-0)0
> 512B   2G 0
>
> $ cat /etc/crypttab
> luks-f691f48b-8556-487d-ac64-50daa99ed4c9
> UUID=f691f48b-8556-487d-ac64-50daa99ed4c9 none luks,discard
>
> $ mount | grep -e discard
> /dev/mapper/luks-f691f48b-8556-487d-ac64-50daa99ed4c9 on / type ext4
> (rw,discard)
> /dev/sda1 on /boot type ext4 (rw,discard)
>
> $ sudo fstrim /boot
> # (same result as Devuan/1 and OpenVZ/6 kernel: success)
>
> $ sudo fstrim /
> fstrim: /: FITRIM ioctl failed: Operation not supported
>
>
> El 26/4/19 a les 21:36, spameden ha escrit:
>
> Hi.
>
> I've asked this question years ago (in 2013):
> https://lists.openvz.org/pipermail/users/2013-August/005250.html
>
> Let me know if it helps, but this bug should have been fixed in CentOS and
> RHEL at least: https://bugs.centos.org/view.php?id=6548
>
> Maybe OpenVZ maintainers didn't pick up this fix in the openvz6 legacy
> kernel?
>
> Thanks.
>
> ср, 10 апр. 2019 г. в 10:45, Narcis Garcia :
>
>> Does anybody know how can I solve this?
>>
>> $ lsb_release -d
>> Description:Devuan GNU/Linux 1.0 (jessie)
>>
>> $ uname -a
>> Linux bell1 2.6.32-openvz-042stab134.8-amd64 #1 SMP Fri Dec 7 17:18:40
>> MSK 2018 x86_64 GNU/Linux
>>
>> $ lsblk --discard /dev/sda
>> NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
>> sda   0  512B   2G 0
>> ├─sda10  512B   2G 0
>> └─sda20  512B   2G 0
>>   └─sda2_crypt00B   0B 0
>>
>> $ cat /etc/crypttab
>> sda2_crypt UUID=* none luks,discard
>>
>> $ mount | grep -e discard
>> /dev/mapper/sda2_crypt on / type ext4
>> (rw,noatime,errors=remount-ro,barrier=1,data=ordered,discard)
>> /dev/sda1 on /boot type ext4 (rw,relatime,barrier=1,data=ordered,discard)
>>
>> $ sudo fstrim /
>> fstrim: /: the discard operation is not supported
>>
>> Thank you.
>>
>>
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>
> ___
> Users mailing 
> listUsers@openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
> ___
> 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

Re: [Users] SSD trim support over a LUKS layer

[spameden]

Hi.

I've asked this question years ago (in 2013):
https://lists.openvz.org/pipermail/users/2013-August/005250.html

Let me know if it helps, but this bug should have been fixed in CentOS and
RHEL at least: https://bugs.centos.org/view.php?id=6548

Maybe OpenVZ maintainers didn't pick up this fix in the openvz6 legacy
kernel?

Thanks.

ср, 10 апр. 2019 г. в 10:45, Narcis Garcia :

> Does anybody know how can I solve this?
>
> $ lsb_release -d
> Description:Devuan GNU/Linux 1.0 (jessie)
>
> $ uname -a
> Linux bell1 2.6.32-openvz-042stab134.8-amd64 #1 SMP Fri Dec 7 17:18:40
> MSK 2018 x86_64 GNU/Linux
>
> $ lsblk --discard /dev/sda
> NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
> sda   0  512B   2G 0
> ├─sda10  512B   2G 0
> └─sda20  512B   2G 0
>   └─sda2_crypt00B   0B 0
>
> $ cat /etc/crypttab
> sda2_crypt UUID=* none luks,discard
>
> $ mount | grep -e discard
> /dev/mapper/sda2_crypt on / type ext4
> (rw,noatime,errors=remount-ro,barrier=1,data=ordered,discard)
> /dev/sda1 on /boot type ext4 (rw,relatime,barrier=1,data=ordered,discard)
>
> $ sudo fstrim /
> fstrim: /: the discard operation is not supported
>
> Thank you.
>
>
> ___
> 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

Re: [Users] simfs support

[spameden]

We're moving away from OpenVZ7 due distribution lock-in, though still using
OpenVZ6 on some Debian hosts.

But, as for the poll, sure simfs should be there! Especially on small ssds
it's a must.

[x] Yes, re-add simfs

2018-07-04 0:06 GMT+03:00 Сергей Мамонов :

> Hi!
>
> +1 for "Yes, re-add simfs"
> from twitterless me,
>
>
> 2018-07-03 23:48 GMT+03:00 Narcis Garcia :
>
>> Same as me about Twiter, but:
>>
>> [ ] No preference
>>
>> [ ] Other (explain)
>>
>> [x] Yes, re-add simfs
>>
>> [ ] No, ploop alone is fine
>>
>>
>>
>> El 03/07/18 a les 21:46, Scott Dowdle ha escrit:
>> > Greetings,
>> >
>> > - Original Message -
>> >> FWIW, I am running this Twitter poll today:
>> >>
>> >> https://twitter.com/solardiz/status/1014124174523150336
>> >
>> > I do not have/want a twitter account so I'll vote here.  You don't have
>> to count it if you don't want to.
>> >
>> > [ ] No preference
>> >
>> > [ ] Other (explain)
>> >
>> > [ ] Yes, re-add simfs
>> >
>> > [x] No, ploop alone is fine
>> >
>> > TYL,
>> >
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>
>
>
> --
> Best Regards,
> Sergey Mamonov
>
> ___
> 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

Re: [Users] no access to .openvz.org ?

[spameden]

Now it works, thanks Dmitry.

2018-02-18 10:27 GMT+03:00 Dmitry Mishin :

> Hi,
>
> I see no problems with them right now. Certificate is valid till 21 April
> 2018.
> Could you please provide details?
>
> Thank you,
> Dmitry.
>
> From:  on behalf of karsten <
> kars...@terragis.net>
> Reply-To: OpenVZ users 
> Date: Friday, 16 February 2018 at 21:44
> To: "users@openvz.org" 
> Subject: [Users] no access to .openvz.org ?
>
> Hi All,
>
> just trying to install a new openvz 7 host machine. One issue I have is
> that I could not download the newest OpenVZ software from
> https://download.openvz.org/ nor mirrors.openvz.org as both give errors
> (and ftp://download.openvz.org/ syas unable to connect):
> uses an invalid security certificate and access is thus blocked for me.
>
> Any ideas what is wrong with the websites and when this could be resolved ?
>
> Cheers
> Karsten
>
> Karsten Vennemann
>
>
> ___
> 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

Re: [Users] no access to .openvz.org ?

[spameden]

there is something wrong with a certificate it seems

2018-02-16 21:44 GMT+03:00 karsten :

> Hi All,
>
> just trying to install a new openvz 7 host machine. One issue I have is
> that I could not download the newest OpenVZ software from
> https://download.openvz.org/ nor mirrors.openvz.org as both give errors
> (and ftp://download.openvz.org/ syas unable to connect):
> uses an invalid security certificate and access is thus blocked for me.
>
> Any ideas what is wrong with the websites and when this could be resolved ?
>
> Cheers
> Karsten
>
> Karsten Vennemann
>
> ___
> 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

Re: [Users] OVZ6 boot freeze on Debian 8

[spameden]

@Stalkr, wow, nice work!  I think I've tried OpenVZ7 kernel some time ago
but didn't have any luck.

Compiling yourself is a hassle althrough unless you make an automatic
repository which will be updated after the new release is pushed.

Is it really worth maintaining yourself the kernel and userland tools to
get OpenVZ working?

Isn't LXC still not production ready?


2017-07-10 11:01 GMT+03:00 StalkR :

> I've been running OpenVZ legacy on Debian 6/7/8 and now 9
> (hosts+containers), works fine. Note I compile my own kernels.
> I recall I had a similar boot freeze in Debian 8, and fixed it by
> installing sysvinit too, but I never copied the inittab and instead choose
> the secondary boot menu (setting init=/lib/sysvinit/init) and since then it
> worked. I upgraded to Debian 9 and still works fine (hosts+containers). Try?
>
> And something to be aware: over time I noticed more problems with
> systemd/openvz: systemd-init not cleaning zombies after a while,
> systemd-tmpfiles boot lockup, systemd-logind timeouts for ssh in
> containers, etc. so recently I removed systemd from a Debian 9 host (start
> with this ) and
> so far so good, I need to do it on more hosts and try with containers too.
>
> I'm also in the process of trying OpenVZ 7 with Debian, so far I have a
> working kernel and I'm trying to get the userland tools working...
>
> On Mon, Jul 10, 2017 at 8:52 AM, Vasily Averin  wrote:
>
>> Dear Narcis,
>> thank you very much!
>>
>> On 2017-07-09 20:41, Narcis Garcia wrote:
>> > To nobody has to add virtualization layers, I've created this guide
>> page:
>> > https://openvz.org/Installation_on_Debian_8
>> >
>> > Thanks.
>> >
>> > El 09/07/17 a les 16:43, Philipp Born ha escrit:
>> >> Hi,
>> >>
>> >> you could try to create your underlying ext4 filesystems on an older
>> >> system with 2.6.32 kernel (CentOS6 live iso for example).
>> >>
>> >> Ran into a similar issue earlier this week, where the PCS6 kernel
>> wasn't
>> >> able to work with an ext4 that was created on a more-recent kernel.
>> >>
>> >> Regards
>> >> Philipp
>> >>
>> >> On 08.07.2017 17:57, Narcis Garcia wrote:
>> >>> Pre-requisite for a Debian 8 (jessie) host is:
>> >>> $ apt-get install sysvinit-core sysvinit-utils
>> >>> $ cp /usr/share/sysvinit/inittab /etc/inittab
>> >>>
>> >>> Then OpenVZ Legacy seems to work perfectly.
>> >>> (For Debian 9 it doesn't seem to be enough)
>> >>>
>> >>>
>> >>> El 08/07/17 a les 16:22, Narcis Garcia ha escrit:
>>  Install procedure:
>> 
>>  RepoFile=/etc/apt/sources.list.d/openvz.list
>>  RepoUrl=http://download.openvz.org/debian
>>  echo "deb $RepoUrl jessie main" | sudo tee "$RepoFile"
>>  echo "deb $RepoUrl wheezy main" | sudo tee -a "$RepoFile"
>>  wget -qO - http://ftp.openvz.org/debian/archive.key | sudo apt-key
>> add -
>>  sudo apt-get --allow-unauthenticated update
>>  KPackage="linux-image-openvz-$(dpkg --print-architecture)"
>>  sudo apt-get install $KPackage ploop initramfs-tools
>>  if [ ! -d /vz ] ; then sudo ln -s /var/lib/vz/ /vz ; fi
>>  sudo reboot
>> 
>>  Attaching screenshots.
>> 
>>  - Tested with 042stab123.9 both with i386 and amd64 architectures.
>>  - [Control]+[Alt]+[Delete] reboots normally.
>> 
>> 
>> 
>>  ___
>>  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
>> >>>
>> >>
>> > ___
>> > 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
>>
>
>
> ___
> 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

Re: [Users] PCI-e NVMe and OpenVZ 6

[spameden]

forget about it

 nvme driver in openvz6 is outdated (performance drawback most likely will
happen or instability), though it's still possible to boot with nvme, if
you patch grub bootloader.

also it's generally recommended to use 3.19+ kernels for nvme, because
driver had 1.0 release there.

though, if you google a bit you can notice there is some performance
degradation in 4.2+ RH kernels for some reason:
http://serverfault.com/questions/733926/nvme-speed-degradation-after-kernel-upgrade


2016-06-20 22:34 GMT+03:00 Nick Knutov :

> Hello all,
>
> will PCI-e NVMe like Intel P3600 and P3608  work with OpenVZ 6 if it is
> not boot drive?
>
> or should I forget about NVMe untill Virtuozzo 7
>
> --
> Best Regards,
> Nick Knutov
> http://knutov.com
> ICQ: 272873706
> Voice: +7-904-84-23-130
>
> ___
> 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

Re: [Users] New setup - deploy OpenVZ or wait for VZ7?

[spameden]

> Please understand me correctly, we don't want to support a variety of all
Linux zoo.
> It requires much more time of development, testing and support.

That's a shame. Another nail in the coffin of OpenVZ.. :(

2016-06-06 19:43 GMT+03:00 jjs - mainphrame :

> Hi Sergey,
>
> I suppose one could still migrate CTs from an OVZ7 pre-release to a
> newly installed OVZ7, is that a reasonable assumption? Is live
> migration likely to work in this scenario?
>
> Jake
>
> On Sun, Jun 5, 2016 at 3:55 AM, Sergey Bronnikov 
> wrote:
> > Hello, Volker
> >
> > On 22:06 Fri 03 Jun , Volker Janzen wrote:
> >> Hi,
> >>
> >> > We are going to release Virtuozzo 7 and OpenVZ 7 not later than this
> July.
> >> > Thank you for your interest and stay tuned!
> >>
> >> when I setup VZ 7 beta now, is it possible to upgrade this to the stable
> >> release when it's released?
> >
> > Unfortunately no. We don't support upgrade from pre-release version to
> the final
> > one.
> >
> >> It also seems to lack some documentation for my use cases, but I need
> to start
> >> with VZ7 sooner or later.
> >
> > What usecases are you talking about?
> >
> >> Regards,
> >>Volker
> >>
> >>
> >> > --
> >> > Best regards,
> >> > Vladimir Porokhov
> >> >
> >> >
> >> >
> >> >
> >> >> On 03.06.16, 18:04, "Scott Dowdle"  behalf of dow...@montanalinux.org> wrote:
> >> >>
> >> >> Greetings,
> >> >>
> >> >> - Original Message -
> >> >>> we need to prepare a new setup composed of a few nodes (probably 5)
> >> >>> for August this year.
> >> >>>
> >> >>> If I interpreted the wii page correctly, the next VZ7 release will
> be
> >> >>> a stable one.  As you can imagine, we're very tempted to wait for it
> >> >>> instead of deploying on OpenVZ and then migrating everything some
> >> >>> months later.
> >> >>>
> >> >>> The only problem is... we have no idea at all about the actual
> >> >>> planned release date.
> >> >>>
> >> >>> Can anyone shed some light on this?  Even knowing the quarter (say,
> >> >>> Q3 vs Q4) would be of great help to us.
> >> >>>
> >> >>> (Disclaimer:  I realise there are many factors involved, that
> >> >>> stability comes at a price of a long(er) development time and I'm
> >> >>> not asking for any commitment to an actual date.  Just a few hints
> >> >>> on 'how close we are' would be more than enough :-)
> >> >>
> >> >> I don't know the answer... as a user and not a dev... but I would
> say deploy OpenVZ Legacy now... and when V7 goes GA... test it out... get
> to know it (or do that with the pre-releases)... and when you feel
> comfortable with it, migrate the containers from OL to V7... and then you
> can wipe your OL hosts and turn them into V7 hosts.  You'd only really need
> one spare and then just cycle through them one by one... but I realize I've
> always operated at a very low scale and there are some really big scale
> operators out there.
> >> >>
> >> >> In any event... who is ready to totally convert even on day one of a
> GA?  Who even advises doing so even if it is convenient?  I'm fairly
> confident that the transition from OL to V7 with container migration should
> be fairly smooth... even without live migration it shouldn't be too much
> trouble if planned for.
> >> >>
> >> >> TYL,
> >> >> --
> >> >> Scott Dowdle
> >> >> 704 Church Street
> >> >> Belgrade, MT 59714
> >> >> (406)388-0827 [home]
> >> >> (406)994-3931 [work]
> >> >> ___
> >> >> 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
> >> >
> >>
> >>
> >> ___
> >> Users mailing list
> >> Users@openvz.org
> >> https://lists.openvz.org/mailman/listinfo/users
> >
> > --
> > sergeyb@
> > ___
> > 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
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] New setup - deploy OpenVZ or wait for VZ7?

[spameden]

2016-06-03 19:17 GMT+03:00 vladimir.porok...@gmail.com <
vladimir.porok...@gmail.com>:

> Hi Guys!
>
> We are going to release Virtuozzo 7 and OpenVZ 7 not later than this July.
> Thank you for your interest and stay tuned!
> --
> Best regards,
> Vladimir Porokhov
>

Is it possible to build kernel packages/userspace utilities for debian
jessie as well ?

Right now there is only kernel/userspaces utilities for debian wheezy and
userspace only for debian jessie.

Thanks

>
>
>
>
> On 03.06.16, 18:04, "Scott Dowdle"  dow...@montanalinux.org> wrote:
>
> >Greetings,
> >
> >- Original Message -
> >> we need to prepare a new setup composed of a few nodes (probably 5)
> >> for August this year.
> >>
> >> If I interpreted the wii page correctly, the next VZ7 release will be
> >> a stable one.  As you can imagine, we're very tempted to wait for it
> >> instead of deploying on OpenVZ and then migrating everything some
> >> months later.
> >>
> >> The only problem is... we have no idea at all about the actual
> >> planned release date.
> >>
> >> Can anyone shed some light on this?  Even knowing the quarter (say,
> >> Q3 vs Q4) would be of great help to us.
> >>
> >> (Disclaimer:  I realise there are many factors involved, that
> >> stability comes at a price of a long(er) development time and I'm
> >> not asking for any commitment to an actual date.  Just a few hints
> >> on 'how close we are' would be more than enough :-)
> >
> >I don't know the answer... as a user and not a dev... but I would say
> deploy OpenVZ Legacy now... and when V7 goes GA... test it out... get to
> know it (or do that with the pre-releases)... and when you feel comfortable
> with it, migrate the containers from OL to V7... and then you can wipe your
> OL hosts and turn them into V7 hosts.  You'd only really need one spare and
> then just cycle through them one by one... but I realize I've always
> operated at a very low scale and there are some really big scale operators
> out there.
> >
> >In any event... who is ready to totally convert even on day one of a GA?
> Who even advises doing so even if it is convenient?  I'm fairly confident
> that the transition from OL to V7 with container migration should be fairly
> smooth... even without live migration it shouldn't be too much trouble if
> planned for.
> >
> >TYL,
> >--
> >Scott Dowdle
> >704 Church Street
> >Belgrade, MT 59714
> >(406)388-0827 [home]
> >(406)994-3931 [work]
> >___
> >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
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] New setup - deploy OpenVZ or wait for VZ7?

[spameden]

2016-06-03 17:14 GMT+03:00 Narcis Garcia :

> We still deploy OpenVZ/6 because we use Debian repositories.
> Our needings are covered with "oldstable" at all.
> I have no information about OpenVZ/7 binary repositories for Debian.
>
>
> El 03/06/16 a les 09:40, Corrado Fiore ha escrit:
> > Dear All,
> >
> > we need to prepare a new setup composed of a few nodes (probably 5) for
> August this year.
> >
> > If I interpreted the wii page correctly, the next VZ7 release will be a
> stable one.  As you can imagine, we're very tempted to wait for it instead
> of deploying on OpenVZ and then migrating everything some months later.
> >
> > The only problem is... we have no idea at all about the actual planned
> release date.
> >
> > Can anyone shed some light on this?  Even knowing the quarter (say, Q3
> vs Q4) would be of great help to us.
>

It really depends on your hardware.

If you're using modern hardware I'd not recommend using CentOS 6/Debian
Wheezy (OpenVZ old kernel).

VZ7 is still in beta, so using it in production is very risky.

Also, if you're using dm-crypt with Full Disk Encryption there might be a
slowdown with 2.6.32 kernel because it doesn't support TRIM for encrypted
devices.

I've been using myself OpenVZ for number of years and really don't like
specific kernel binding (e.g. for OpenVZ 2.6.32 rhel6 and for VZ7 3.10
rhel7).

The only alternative for modern hardware (e.g. NVME PCI-E ssds or some
modern SSDs) is to use upstream distro kernel with LXC/KVM.


>
> > (Disclaimer:  I realise there are many factors involved, that stability
> comes at a price of a long(er) development time and I'm not asking for any
> commitment to an actual date.  Just a few hints on 'how close we are' would
> be more than enough :-)
> >
> > Thanks a lot,
> > Corrado Fiore
> > ___
> > 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
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Website trackers (OT)

[spameden]

there are bunch of plugins for Firefox to mitigate this:

AdBlock Plus, Ghostery, NoScript.

Check 'em out.

2015-09-26 16:11 GMT+03:00 Narcis Garcia :

> Are you "internet"?
> Or do you have only your own cookies?
>
> Welcome to the XXI century internet, we are used as a product by
> companies unrelated to websites we visit.
>
>
> El 25/09/15 a les 19:30, Todd Mueller ha escrit:
> > Welcome to the Internet, we have cookies.
> >
> > On Fri, Sep 25, 2015 at 10:09 AM, Narcis Garcia 
> wrote:
> >> Off topic:
> >> This wiki is served with, at least, 4 spyware elements:
> >> - Facebook connect
> >> - Google analytics
> >> - Google+ platform
> >> - Twitter button
> >>
> >>
> >> El 25/09/15 a les 13:54, Sergey Bronnikov ha escrit:
> >>> Hello, everyone
> >>>
> >>> some of you asked about feature set of Virtuzzo 7 and difference
> between free
> >>> and commercial versions.  We have prepared table with feature
> comparison for
> >>> OpenVZ -stable, Virtuozzo 7 and other virtualization solutions -
> >>> https://openvz.org/Comparison
> >>>
> >>> Pay attention it is not a final feature set, some features can be
> added in
> >>> future till final release.
> >>>
> >>>
> >>> --
> >>> sergeyb@
> >>> ___
> >>> 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
> > ___
> > 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
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] HA: measuring IO inside an openvz container?

[spameden]

2015-09-04 17:32 GMT+03:00 Konstantin Bukharov :

> Hi,
>
> We suggest our internal tool available at
> http://download.openvz.org/~akirov/at_io_iops/


is there a sourcecode for it?


>
>
> Some useful options and scenario are described there -
>
> http://download.cloudserver.odin.com/doc/pstorage/parallels_cloud_storage_io
> _benchmarking_guide-1.pdf
>
> Best regards,
> Konstantin Bukharov
>
>
> -Исходное сообщение-
> От: users-boun...@openvz.org [mailto:users-boun...@openvz.org] От имени
> Kevin Holly [Fusl]
> Отправлено: Friday, September 4, 2015 17:02
> Кому: users@openvz.org
> Тема: Re: [Users] measuring IO inside an openvz container?
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> AFAIK there is no such tool that displaye you the configured IO options on
> the hardware node.
>
> You can test if ioping (https://github.com/koct9i/ioping) or iotop
> (http://guichaz.free.fr/iotop/) give you some more debug information about
> this.
>
> On 09/04/2015 02:28 PM, Benjamin Henrion wrote:
> > Hi,
> >
> > I do have an account on an openvz server, but the IO provided is very
> > variable, sometimes my shell is fluid, sometimes it is really slow.
> >
> > Is there a test I could run periodically to test the disk IO?
> >
> > Best,
> >
>
> - --
> Best regards
>
> Kevin Holly - r...@hallowe.lt - http://hallowe.lt/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJV6aRFAAoJELAaqP3QtzpMBL4H/164pBrZzOIEnxhYWMxegYV8
> wBO6jqDaM0iRegwIQScF6pKMEokFqzk6KmWJCuzvCOFAWE2c+LoJ03w0XDsV/jOq
> Z4BRWs5BGbzPOuZhTZt405Kfd/HD2hy0ho3LB/8Bh+CfO4+f94RGEY9FhLPTqzOf
> mkinWFwOVAAGfpNMxmrPOEgqeXEyai3nLnA7SyROYjJ9T86inc1JXl6wR12KmV0S
> tDtfqblc4IhHf0anBW+uzpiz7Be1vzjj/3vyjRfTmrXxGbFmqzaF8qrwMYSOQ/05
> 0r6Qtd6565cCTpFvcylRVQtS5UUTfTl+SwgyclgAG0iCK8R5rlfgp7jh6/mxSao=
> =UbuR
> -END PGP SIGNATURE-
> ___
> 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
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Virtuzzo branding: "vzctl" vs "prlctl"

[spameden]

2015-08-04 17:54 GMT+03:00 Scott Dowdle :

> Greetings,
>
> I say vzctl as vee zee cee tee el.  Adding one extra letter and saying pee
> arr el cee tee el is no mental challenge.  prlctl is no more oddly named
> than a handful of other unix/linux commands we use on a daily basis.
>

I'm sorry but for me prlctl is more confusing than vzctl, simply because
it's very easy to write prctl instead for example.


>
> You guys need to quit nit-picking every little thing because there are
> tons of hard-core technical things that are more important.  There will be
> plenty of time for nit-picking later.
>

> The transition from SWsoft to Parallels to Odin and from OpenVZ to
> Virtuozzo has indeed been sloppy... but if you've paid even the slightest
> bit of attention to the IT industry, you'll see that it is littered with
> failures, buyouts, mergers and all kinds of product gene-splicing... and I
> think morphing of the product this mailing list is about hasn't been so bad
> over the almost 10 years it has existed.
>

Well if you want to look something perfect you need some sort of a standard
to follow.. So If there is some sort of mess in branding there might be
another mess and more bugs.. Don't you think it's better to have 1 product
rather than 100500 products giving basically the same functionality? And
also unified branding is much better for marketing purposes.


>
> Now having said all of that, I do appreciate that you care enough to think
> about all of this stuff and give advice... but I imagine the folks making
> the decisions are a few levels above the employees reading your posts.
> Perhaps they will be able to act on some of your suggestions but if not,
> don't suffer over it.
>

I personally don't care much how tools are named as long as they are
working properly and you know which tool you need to use.


>
> TYL,
> --
> Scott Dowdle
> 704 Church Street
> Belgrade, MT 59714
> (406)388-0827 [home]
> (406)994-3931 [work]
> ___
> 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

Re: [Users] Virtuzzo branding: "vzctl" vs "prlctl"

[spameden]

+1 on all points raised by Gena!

2015-08-03 14:18 GMT+03:00 Sergey Bronnikov :

> On 13:28 Mon 03 Aug , Gena Makhomed wrote:
> > On 03.08.2015 12:56, Sergey Bronnikov wrote:
> >
> > >we have published a part of Virtuzzo documentation on separate
> > >site - http://docs.openvz.org/. And we will add more docs soon.
> >
> > See:
> >
> >
> http://docs.openvz.org/virtuozzo_7_readme.webhelp/_installing_virtuozzo_7_technical_preview_in_virtual_machines.html
> >
> > 1) name of tool is "prlctl" - prefix "prl" come from "Parallels"
> > 2) brand name in left top corner of site is "Odin"
> > 3) domain name openvz.org come from "OpenVZ"
> > 4) product name is "Virtuzzo"
> >
> > So, in one page you have mess of four brands:
> >
> > "Parallels", "Odin", "OpenVZ", "Virtuzzo".
>
> I'm totally agree with you.
> We will fix it in scope of
> https://bugzilla.openvz.org/show_bug.cgi?id=3288
>
> > Your marketologs really think,
> > what such crazy mess of brands is good for your product?
> >
> > For example, prefix "prl" is really need in product "Virtuzzo"
> > developed now by "Odin" company, based on the "OpenVZ" product?
> >
> > If "Virtuzzo" is proposed as upgrade for "OpenVZ"
> > - may be it is better to save old tool prefix "vz" ?
> >
> > "vzctl" name means "Virtuozzo control" - very good and useful name.
> > same as "vzkernel" means "Virtuozzo kernel" - easy to understand.
> >
> > "prlctl" means unpronounceable name of six strange consonant letters
> > and now it without any sense and relation to the "Virtuzzo" product.
> >
> > For example, I am, as 5-year user of OpenVZ does not see any sense
> > in renaming very useful and familiar "vzctl" into alien "prlctl".
> >
> > Probably all other OpenVZ/vzctl users have the similar impression.
> ___
> 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

Re: [Users] "Virtuzzo" vs "OpenVZ"

[spameden]

Completely agree with Gena on this one.

It should be more clear for end users:

e.g. there should be some kinda comparison between Open Source version and
Commercial, as nginx did on their site:

https://www.nginx.com/products/ (click on Compare)

Also +1 on the domains idea:
if you don't want to alter much, you could just redirect virtuozzo.org to
openvz.org site or specific URL where virtuozzo is described


2015-08-03 20:07 GMT+03:00 jjs - mainphrame :

> For those so inclined, a parallel track with the openvz learning
> experience: http://www.russianpod101.com/ ;)
>
> On Mon, Aug 3, 2015 at 9:54 AM, Scott Dowdle 
> wrote:
>
>> Greetings,
>>
>> - Original Message -
>> > On 03.08.2015 17:09, Sergey Bronnikov wrote:
>> > Ok, but what is the difference between
>> > free and open source version of Virtuzzo 7
>> > and paid version of Virtuzzo 7 from Odin ?
>>
>> Also, there is a rather primitive and somewhat incomplete Comparison wiki
>> page that is liked to on the openvz.org front page:
>>
>> http://wiki.openvz.org/Comparison
>>
>> I think a bit of the challenge is that Sergey's native language is
>> Russian and I'm not sure what Gena's native language is (Russian too?)...
>> and you guys are talking to each other in English.  My guess is a LOT of
>> the meaning and tone get lost in the multiple translations... but whatcha'
>> gonna' do?
>>
>> TYL,
>> --
>> Scott Dowdle
>> 704 Church Street
>> Belgrade, MT 59714
>> (406)388-0827 [home]
>> (406)994-3931 [work]
>> ___
>> 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
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Kernel 3.10 packages availability

[spameden]

Would be nice to get packaging scripts for linux-image-openvz-amd64 somehow
to try to build 3.10 kernel from the source provided via git repository.

2015-07-25 5:58 GMT+03:00 spameden :

>
>
> 2015-07-25 5:07 GMT+03:00 Kir Kolyshkin :
>
>>
>>
>> On 07/24/2015 06:38 PM, spameden wrote:
>>
>> I see there is a 3.10 kernel branch here:
>> <https://src.openvz.org/projects/OVZ/repos/vzkernel/browse>
>> https://src.openvz.org/projects/OVZ/repos/vzkernel/browse
>>
>>  Is it considered stable?
>>
>>
>> Looks like you missed all the hype about VZ7:
>> https://lists.openvz.org/pipermail/announce/2015-April/000579.html
>>
>
> Weird, seems I really did miss this announce for some reason.
>
>
>>
>>
>> In short -- this is beta, and RPM packages are available:
>> https://lists.openvz.org/pipermail/announce/2015-July/000606.html
>>
>
> Alright, i'll give it a shot, thanks.
>
> I think i have somewhere laying scripts to convert RPM->DEB though not
> sure if kernel will work on Debian 7 without issues.
>
>
>>
>> As far as I no, currently no DEB packages are planned, but as we are
>> the community we can still make it happen!
>>
>
> Second that, maybe Ola Lundqvist will help with debian scripts used to
> provide 2.6.32 kernels and other packages automatically built for debian?
>
>>
>> PS please consider subscribing to announce@:
>> https://lists.openvz.org/mailman/listinfo/announce
>>
>
> Yeah, I'm subscribed already, but thanks anyways!
>
>>
>>
>> ___
>> 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

Re: [Users] Kernel 3.10 packages availability

[spameden]

2015-07-25 5:07 GMT+03:00 Kir Kolyshkin :

>
>
> On 07/24/2015 06:38 PM, spameden wrote:
>
> I see there is a 3.10 kernel branch here:
> <https://src.openvz.org/projects/OVZ/repos/vzkernel/browse>
> https://src.openvz.org/projects/OVZ/repos/vzkernel/browse
>
>  Is it considered stable?
>
>
> Looks like you missed all the hype about VZ7:
> https://lists.openvz.org/pipermail/announce/2015-April/000579.html
>

Weird, seems I really did miss this announce for some reason.


>
>
> In short -- this is beta, and RPM packages are available:
> https://lists.openvz.org/pipermail/announce/2015-July/000606.html
>

Alright, i'll give it a shot, thanks.

I think i have somewhere laying scripts to convert RPM->DEB though not sure
if kernel will work on Debian 7 without issues.


>
> As far as I no, currently no DEB packages are planned, but as we are
> the community we can still make it happen!
>

Second that, maybe Ola Lundqvist will help with debian scripts used to
provide 2.6.32 kernels and other packages automatically built for debian?

>
> PS please consider subscribing to announce@:
> https://lists.openvz.org/mailman/listinfo/announce
>

Yeah, I'm subscribed already, but thanks anyways!

>
>
> ___
> 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

[Users] Kernel 3.10 packages availability

[spameden]

I see there is a 3.10 kernel branch here:
https://src.openvz.org/projects/OVZ/repos/vzkernel/browse

Is it considered stable?

Is there any plan to make packages (e.g. for Debian distributions) ?

Would be nice to have an updated kernel for OpenVZ packaged automatically
and get updates when you push some security updates etc..

Many thanks.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] ZFS vs ploop

[spameden]

Completely agree with Gena Makhomed on points he raised about ploop.

If you run HN on SSD (256gb for example) ploop is not good to use at all,
too much overhead of space.

Would be nice to have better free space management in ploop somehow.

Also about OpenVZ restore option:

Here is real example from production environment: kannel (http://kannel.org)
is not working properly with OpenVZ suspend/restore feature (turned on by
default), so had to use VE_STOP_MODE=stop instead.

2015-07-24 15:41 GMT+03:00 Gena Makhomed :

> On 23.07.2015 5:44, Kir Kolyshkin 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 this: run "/usr/sbin/vzctl compact $CT"
>>> via cron every night, and now ploop image has less overhead.
>>>
>>> current state:
>>>
>>> on hardware node:
>>>
>>> # du -b /vz/private/155/root.hdd
>>> 205963399961/vz/private/155/root.hdd
>>>
>>> inside container:
>>>
>>> # df -B1
>>> Filesystem   1B-blocks  UsedAvailable Use%
>>> Mounted on
>>> /dev/ploop38149p1 270426705920  163129053184  94928560128  64% /
>>>
>>> 
>>>
>>> used space, bytes: 163129053184
>>>
>>> image size, bytes: 205963399961
>>>
>>> "ext4 over ploop over ext4" solution disk space overhead is near 26%,
>>> or is near 40 GiB, if see this disk space overhead in absolute numbers.
>>>
>>> This is main disadvantage of ploop.
>>>
>>> And this disadvantage can't be avoided - it is "by design".
>>>
>>
>> To anyone reading this, there are a few things here worth noting.
>>
>> a. Such overhead is caused by three things:
>> 1. creating then removing data (vzctl compact takes care of that)
>> 2. filesystem fragmentation (we have some experimental patches to ext4
>>  plus an ext4 defragmenter to solve it, but currently it's still in
>> research stage)
>> 3. initial filesystem layout (which depends on initial ext4 fs size,
>> including inode requirement)
>>
>> So, #1 is solved, #2 is solvable, and #3 is a limitation of the used
>> file system and can me mitigated
>> by properly choosing initial size of a newly created ploop.
>>
>
> this container is compacted every night, during working day
> only new static files added to container, this container does
> not contain many "creating then removing data" operations.
>
> current state:
>
> on hardware node:
>
> # du -b /vz/private/155/root.hdd
> 203547480857/vz/private/155/root.hdd
>
> inside container:
>
> # df -B1
> Filesystem   1B-blocks  UsedAvailable Use% Mounted
> on
> /dev/ploop55410p1 270426705920  163581190144  94476423168  64% /
>
>
> used space, bytes: 163581190144
>
> image size, bytes: 203547480857
>
> overhead: ~ 37 GiB, ~ 19.6%
>
> container was compacted at 03:00
> by command /usr/sbin/vzctl compact 155
>
> run container compacting right now:
> 9443 clusters have been relocated
>
> result:
>
> used space, bytes: 163604983808
>
> image size, bytes: 193740149529
>
> overhead: ~ 28 GiB, ~ 15.5%
>
> I think this is not good idea run ploop compaction more frequently,
> then one time per day at the night - so we need take into account
> not minimal value of overhead, but maximal one, after 24 hours
> of container work in normal mode - to planning disk space
> on hardware node for all ploop images.
>
> so real overhead of ploop can be accounted only
> after at lest 24h of container being in running state.
>
>  A example of #3 effect is this: if you create a very large filesystem
>> initially (say, 16TB) and then downsize it (say, to 1TB), filesystem
>> metadata overhead will be quite big. Same thing happens if you ask
>> for lots of inodes (here "lots" means more than a default value which
>> is 1 inode per 16K of disk space). This happens because ext4
>> filesystem is not designed to shrink. Therefore, to have lowest
>> possible overhead you have to choose the initial filesystem size
>> carefully. Yes, this is not a solution but a workaround.
>>
>
> as you can see by inodes:
>
> # df -i
> Filesystem Inodes IUsed IFree IUse% Mounted on
> /dev/ploop55410p1 16777216 1198297 15578919 8% /
>
> initial filesystem size was 256 GiB:
>
> c (16777216 * 16 * 1024) / 1024.0/1024.0/1024.0 == 256 GiB.
>
> current filesystem size is also 256 GiB:
>
> # cat /etc/vz/conf/155.conf | grep DISKSPACE
> DISKSPACE="268435456:268435456"
>
> so there is no extra "filesystem metadata overhead".
>
> what I am doing wrong, and how I can decrease ploop overhead here?
>
> I found only one way: migrate to ZFS with turned on lz4 compression.
>
>  Also note, that ploop was not designed with any specific filesystem in
>> mind, it is universal, so #3 can be solved by moving to a different fs in
>> the future.
>>
>
> XFS currently not support filesystem snrinking at all:
> http://xfs.org/index.php/Shrinking_

Re: [Users] The future of OpenVZ: Virtuozzo Core

[spameden]

2014-12-27 3:53 GMT+03:00 jjs - mainphrame :

> Excellent!
>
> On Fri, Dec 26, 2014 at 3:59 PM, Kir Kolyshkin  wrote:
>
>> Please  read this very important announce:
>>
>> http://openvz.livejournal.com/49158.html
>
>
That's some really great news!

New kernel features and faster development always pushing forward.

Happy NYE.


>>
>> Happy New Year,
>>   OpenVZ team.
>> ___
>> 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
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Installing AMD GPU driver

[spameden]

2014-08-02 0:13 GMT+04:00 Harry Koris :

> Hi,
>
> I'm looking to install AMD 13.25 APU Driver so that I can access the
> on-board graphics from within a Centos-x86_64 container. I've added the PCI
> slot that the GPU comes up on using the '--pci_add' option but the driver
> still reads out that no compatible adapters were found. If I run 'lspci' in
> the container the GPU does show up. I have the driver running on the HE
> fine.
>
> Is there a certain device that I can add to the container?
> Is it possible to modprobe the driver from the hardware, into the
> container?
> As a side note, I do have the module loaded on the hardware node prior to
> launching the container.
>
> Any information that may help is appreciated.
>

You probably need to forward certain /dev/* entries to your CT and allow
them for writing.

It might be not 100% secure and really depends on the driver (if there is
some issues, it could lead potentially that someone could get out of CT to
HN via driver device).


>
> Thank you,
> Harry Koris
>
> ___
> 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

Re: [Users] openvpn in openvz

[spameden]

2014-06-25 22:19 GMT+04:00 Rene C. :

> No, I went in the direction of l2tp as recommended. It both seems more
> secure and more compatible with both windows and android clients than
> openvpn.
>


'more secure' ?

did you audit OpenVPN/OpenSSL code? How can you say so.

There are clients for both android and windows for OpenVPN.

Anyways, if you've decided to go with IPSec go over with it, it should work
too.



>
>
> I still get the "Checking for IPsec support in kernel
>[FAILED]" error from the check, although the latest openvz
> kernel is now installed.
>
> What can we do to narrow down the cause of this?
>

tbh, I have no idea, had no experience with IPSec setup on OpenVZ, ask the
guy who've suggested ipsec setup.


> On Mon, Jun 23, 2014 at 7:56 PM, spameden  wrote:
> >
> >
> >
> > 2014-06-23 11:31 GMT+04:00 Rene C. :
> >>
> >> Sorry, still stuck:
> >
> >
> > Did you try OpenVPN configuration that I've suggested?
> >
> > About IPSEC: not sure, check your syslog logs might give you some tips.
> >>
> >>
> >> [root@server14 ~]# uname -a
> >> Linux server14.-sanitized- 2.6.32-042stab090.4 #1 SMP Mon Jun 16
> >> 15:13:38 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux
> >> [root@server14 ~]# for x in tun ppp_async pppol2tp
> >> xfrm4_mode_transport xfrm4_mode_tunnel xfrm_ipcomp esp4; do lsmod |
> >> grep $x; done
> >> xfrm4_mode_tunnel   2019  0
> >> tun19157  0
> >> ppp_async   7874  0
> >> ppp_generic25400  3 pppol2tp,pppox,ppp_async
> >> crc_ccitt   1733  1 ppp_async
> >> pppol2tp   22749  0
> >> pppox   2712  1 pppol2tp
> >> ppp_generic25400  3 pppol2tp,pppox,ppp_async
> >> xfrm4_mode_transport 1465  0
> >> xfrm4_mode_tunnel   2019  0
> >> xfrm_ipcomp 4626  0
> >> esp45406  0
> >> [root@server14 ~]# vzctl enter 1418
> >> entered into CT 1418
> >> [root@vps1418 /]# ipsec verify
> >> Checking your system to see if IPsec got installed and started
> correctly:
> >> Version check and ipsec on-path  [OK]
> >> Linux Openswan U2.6.32/K(no kernel code presently loaded)
> >> Checking for IPsec support in kernel [FAILED]
> >>  SAref kernel support[N/A]
> >> Checking that pluto is running   [OK]
> >>  Pluto listening for IKE on udp 500  [FAILED]
> >>  Pluto listening for NAT-T on udp 4500   [FAILED]
> >> Checking for 'ip' command[OK]
> >> Checking /bin/sh is not /bin/dash[OK]
> >> Checking for 'iptables' command  [OK]
> >> Opportunistic Encryption Support [DISABLED]
> >>
> >> What am I missing?
> >>
> >> On Mon, Jun 23, 2014 at 1:12 AM, Rene C.  wrote:
> >> > Yep, rebooted the container.
> >> >
> >> > Here's the modules present:
> >> >
> >> > [root@server18 ~]# lsmod
> >> > Module  Size  Used by
> >> > esp45406  0
> >> > xfrm_ipcomp 4626  0
> >> > xfrm4_mode_tunnel   2019  0
> >> > pppol2tp   22749  0
> >> > pppox   2712  1 pppol2tp
> >> > ppp_async   7874  0
> >> > ppp_generic25400  3 pppol2tp,pppox,ppp_async
> >> > slhc5821  1 ppp_generic
> >> > crc_ccitt   1733  1 ppp_async
> >> > vzethdev8221  0
> >> > vznetdev   18952  10
> >> > pio_nfs17576  0
> >> > pio_direct 28261  9
> >> > pfmt_raw3213  0
> >> > pfmt_ploop1 6320  9
> >> > ploop 116096  23
> pio_nfs,pio_direct,pfmt_raw,pfmt_ploop1
> >> > simfs   4448  0
> >> > vzrst 196693  0
> >> > vzcpt 148911  1 vzrst
> >> > nfs   442438  3 pio_nfs,vzrst,vzcpt
> >> > lockd  77189  2 vzrst,nfs
> >> > fscache55684  1 nfs
> >> > auth_rpcgss44949  1 nfs
>

Re: [Users] openvpn in openvz

[spameden]

2014-06-23 11:31 GMT+04:00 Rene C. :

> Sorry, still stuck:
>

Did you try OpenVPN configuration that I've suggested?

About IPSEC: not sure, check your syslog logs might give you some tips.

>
> [root@server14 ~]# uname -a
> Linux server14.-sanitized- 2.6.32-042stab090.4 #1 SMP Mon Jun 16
> 15:13:38 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux
> [root@server14 ~]# for x in tun ppp_async pppol2tp
> xfrm4_mode_transport xfrm4_mode_tunnel xfrm_ipcomp esp4; do lsmod |
> grep $x; done
> xfrm4_mode_tunnel   2019  0
> tun19157  0
> ppp_async   7874  0
> ppp_generic25400  3 pppol2tp,pppox,ppp_async
> crc_ccitt   1733  1 ppp_async
> pppol2tp   22749  0
> pppox   2712  1 pppol2tp
> ppp_generic25400  3 pppol2tp,pppox,ppp_async
> xfrm4_mode_transport 1465  0
> xfrm4_mode_tunnel   2019  0
> xfrm_ipcomp 4626  0
> esp45406  0
> [root@server14 ~]# vzctl enter 1418
> entered into CT 1418
> [root@vps1418 /]# ipsec verify
> Checking your system to see if IPsec got installed and started correctly:
> Version check and ipsec on-path  [OK]
> Linux Openswan U2.6.32/K(no kernel code presently loaded)
> Checking for IPsec support in kernel [FAILED]
>  SAref kernel support[N/A]
> Checking that pluto is running   [OK]
>  Pluto listening for IKE on udp 500  [FAILED]
>  Pluto listening for NAT-T on udp 4500   [FAILED]
> Checking for 'ip' command[OK]
> Checking /bin/sh is not /bin/dash[OK]
> Checking for 'iptables' command  [OK]
> Opportunistic Encryption Support [DISABLED]
>
> What am I missing?
>
> On Mon, Jun 23, 2014 at 1:12 AM, Rene C.  wrote:
> > Yep, rebooted the container.
> >
> > Here's the modules present:
> >
> > [root@server18 ~]# lsmod
> > Module  Size  Used by
> > esp45406  0
> > xfrm_ipcomp 4626  0
> > xfrm4_mode_tunnel   2019  0
> > pppol2tp   22749  0
> > pppox   2712  1 pppol2tp
> > ppp_async   7874  0
> > ppp_generic25400  3 pppol2tp,pppox,ppp_async
> > slhc5821  1 ppp_generic
> > crc_ccitt   1733  1 ppp_async
> > vzethdev8221  0
> > vznetdev   18952  10
> > pio_nfs17576  0
> > pio_direct 28261  9
> > pfmt_raw3213  0
> > pfmt_ploop1 6320  9
> > ploop 116096  23 pio_nfs,pio_direct,pfmt_raw,pfmt_ploop1
> > simfs   4448  0
> > vzrst 196693  0
> > vzcpt 148911  1 vzrst
> > nfs   442438  3 pio_nfs,vzrst,vzcpt
> > lockd  77189  2 vzrst,nfs
> > fscache55684  1 nfs
> > auth_rpcgss44949  1 nfs
> > nfs_acl 2663  1 nfs
> > sunrpc268245  6 pio_nfs,nfs,lockd,auth_rpcgss,nfs_acl
> > vziolimit   3719  0
> > vzmon  24462  8 vznetdev,vzrst,vzcpt
> > ip6table_mangle 3669  0
> > nf_nat_ftp  3523  0
> > nf_conntrack_ftp   12929  1 nf_nat_ftp
> > iptable_nat 6302  1
> > nf_nat 23213  3 vzrst,nf_nat_ftp,iptable_nat
> > xt_length   1338  0
> > xt_hl   1547  0
> > xt_tcpmss   1623  0
> > xt_TCPMSS   3461  1
> > iptable_mangle  3493  0
> > xt_multiport2716  0
> > xt_limit2134  0
> > nf_conntrack_ipv4   9946  5 iptable_nat,nf_nat
> > nf_defrag_ipv4  1531  1 nf_conntrack_ipv4
> > ipt_LOG 6405  0
> > xt_DSCP 2849  0
> > xt_dscp 2073  0
> > ipt_REJECT  2399  12
> > tun19157  0
> > xt_owner2258  0
> > vzdquota   55339  0 [permanent]
> > vzevent 2179  1
> > vzdev   2733  5
> vzethdev,vznetdev,vziolimit,vzmon,vzdquota
> > iptable_filter  2937  5
> > ip_tables  18119  3 iptable_nat,iptable_mangle,iptable_filter
> > ip6t_REJECT 4711  2
> > nf_conntrack_ipv6   8353  2
> > nf_defrag_ipv6 11188  1 nf_conntrack_ipv6
> > xt_state1508  4
> > nf_conntrack   80313  9
> >
> vzrst,vzcpt,nf_nat_ftp,nf_conntrack_ftp,iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
> > ip6table_filter 3033  1
> > ip6_tables 18988  2 ip6table_mangle,ip6table_filter
> > ipv6  322874  1627
> > vzrst,ip6table_mangle,ip6t_REJECT,nf_conntrack_ipv6,nf_defrag_ipv6
> > iTCO_wdt7147  0
> > iTCO_vendor_support 3072  1 iTCO_wdt
> > i2c_i801   11375  

Re: [Users] openvpn in openvz

[spameden]

2014-06-21 10:47 GMT+04:00 Rene C. :

> I got the openvpn part itself down, no problem, but getting it to work
> in a container is a lot of hassle. Many pages, but most are outdated
> and things keeps changing. Anyone know how to get it to work TODAY?
>
> The server is an otherwise normal server with public ip addresses and
> works with cpanel, no problem that far. The problem is getting an
> openvpn service to work in it.
> s
> - which modules to insmod on the hwnode
>
$ *cat /etc/modules*

#Iptables
ip_tables
iptable_filter
iptable_mangle
ipt_limit
ipt_multiport
ipt_tos
ipt_REJECT
ipt_TCPMSS
ipt_tcpmss
ipt_ttl
ipt_length
ip_conntrack
ipt_state
ipt_connlimit
ipt_recent
ipt_comment
xt_comment



> - which modules to add into /etc/vz/vz.conf
>

*/etc/vz/vz.conf*:
IPTABLES_MODULES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter
iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ip6_tables
ip6table_filter ip6table_mangle ip6t_REJECT"

> - which modules to add into /etc/vz/.conf
>

*/etc/vz/conf/2xx.conf:*

DEVNODES="net/tun:rw "
DEVICES="c:10:200:rw "
CAPABILITY=" NET_ADMIN:on"
IPTABLES="ip_tables iptable_filter iptable_mangle ipt_limit ipt_multiport
ipt_tos ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ip_conntrack
ipt_state ipt_recent iptable_nat "


Make sure you add this on your HN in mangle table (note replace eth0 with
your outbound internet interface):
# Generated by iptables-save v1.4.14 on Sun Jun 22 23:05:56 2014
*mangle
:PREROUTING ACCEPT [106874720:35868997787]
:INPUT ACCEPT [73771015:17894674066]
:FORWARD ACCEPT [33103560:17974356407]
:OUTPUT ACCEPT [63966614:112159146298]
:POSTROUTING ACCEPT [97050402:130132419523]
-A FORWARD -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu
COMMIT
# Completed on Sun Jun 22 23:05:56 2014

this rule fixes issue with low MTU packets.


*settings inside CT:*
/etc/openvpn/server.conf:
fragment 1420
mssfix

these two settings fixes issues as well with low TCP mtu.


Firewall settings in the container for OpenVPN:
*/etc/iptables.rules *in CT (note replace  port with your OpenVPN
server port and 1.2.3.4 with your external IP of CT):

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:Firewall - [0:0]
-A INPUT -s 10.8.1.0/24 -j ACCEPT
-A INPUT -j Firewall
-A FORWARD -d 10.8.1.0/24 -j ACCEPT
-A FORWARD -s 10.8.1.0/24 -j ACCEPT
-A Firewall -p udp -m udp --dport  -m state --state NEW -m comment
--comment "OpenVPN server" -j ACCEPT
-A Firewall -i lo -j ACCEPT
-A Firewall -m state --state RELATED,ESTABLISHED -j ACCEPT
-A Firewall -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Thu Jun  5 15:31:33 2014
# Generated by iptables-save v1.4.14 on Thu Jun  5 15:31:33 2014
*mangle
:PREROUTING ACCEPT [97586930:43802318561]
:INPUT ACCEPT [31215292:5102519658]
:FORWARD ACCEPT [66363273:38698230987]
:OUTPUT ACCEPT [44914356:38872135945]
:POSTROUTING ACCEPT [111277625:77570366051]
COMMIT
# Completed on Thu Jun  5 15:31:33 2014
# Generated by iptables-save v1.4.14 on Thu Jun  5 15:31:33 2014
*nat
:PREROUTING ACCEPT [3571417:259748350]
:POSTROUTING ACCEPT [1726:125927]
:OUTPUT ACCEPT [1727:126000]
-A POSTROUTING -s 10.8.1.0/24 -j SNAT --to-source 1.2.3.4
COMMIT





___
> 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

Re: [Users] "No ploop support" message on Centos 5 with vzctl 4.7

[spameden]

Hi.

Any update on this?

Sorry If I am bothering you guys too much, just bit of annoy for me:

# vzlist
Can't load ploop library: libploop.so: cannot open shared object file: No
such file or directory
Please install ploop packages!



2014-04-28 16:09 GMT+04:00 Aleksandar Ivanisevic :

> Kir Kolyshkin  writes:
>
> [...]
>
> > So, unless you are doing something like 2>&1 when calling vzlist, this
> bug
> > is not affecting you, thus not "breaking half of the scripts". If you
> > do 2>&1,
> > this is the wrong thing to do and you should fix (half of?) your
> > scripts.
>
> Well, I guess it depends on how do you define breakage. In my
> environment, output on stderr when there are no actual errors
> causes a lot of monitoring alerts, emails from cron and whatnot, and I
> consider that a breakage.
>
> > Nevertheless, I will fix it in 4.7.1 (not sure about the timing though).
> > Sorry for the trouble.
>
> No problem, it wasn't really a complaint, you missed a smiley ;)
>
> --
> Ti si arogantan, prepotentan i peglaš vlastitu frustraciju. -- Ivan
> Tišljar, hr.comp.os.linux
>
> ___
> 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

Re: [Users] Issues with kernel upgrade on Debian Wheezy

[spameden]

I can confirm there is an issue in upgrading on wheezy (stable).

It uses linux-image-openvz-amd64  042+1 instead of
the regular version and generates /boot/vmlinuz-2.6.32-openvz-amd64 instead
of the prefixed version, i.e.:
/boot/vmlinuz-2.6.32-openvz-042stab084.17-amd64

Could you guy look into it and fix it completely, so upgrades will go fine
and not break anything?


2014-03-26 21:21 GMT+04:00 Narcis Garcia :

> These may be alternatives for version numbering (I've tested them with
> dpkg --compare-versions):
>
> As a complete upstream version:
> 42.85.20
> Combining old and new schema:
> 042+stab085.20
>
>
> El 26/03/14 17:07, Roman Haefeli ha escrit:
> > On Mon, 2014-03-24 at 09:40 -0700, Kir Kolyshkin wrote:
> >> Thank you for detailed position. I have already rolled back to the old
> >> versioning scheme,
> >> please check packages in wheezy-test and let me know if anything is
> >> wrong there.
> >
> > Things look pretty good in wheezy-test. Thanks for the work.
> >
> > Two minor issues:
> >
> > * There is still no changelog of the kernel in the package (or
> >   I cannot find it, usually it goes to something like:
> >
> /usr/share/doc/linux-image-2.6.32-openvz-042stab085.20-amd64/changelog.Debian.gz
> >
> > * The version of the meta package linux-image-openvz-amd64 is higher
> >   (042+1) in wheezy than in wheezy-test (042stab085.20). When switching
> >   from wheezy to wheezy-test, one has to remove and re-install the
> >   package linux-image-openvz-amd64 in order to automatically install the
> >   newest kernel packagelinux-image-2.6.32-openvz-042stab085.20-amd64
> >
> > I'm not sure how to resolve the latter problem or whether it should be
> > addressed at all (switching from wheezy to wheezy-test can considered to
> > be one time thing). However, once the the current wheezy-test
> > linux-image-openvz-amd64  goes to wheezy, there is a problem because you
> > cannot downgrade packages. Either the version needs to be bumped with an
> > epoch version [1] like 1:042stab085.20 (ugly) or the versioning scheme
> > needs to be adapted (perhaps also ugly), but how? I can't think of a
> > truly satisfying solution right now.
> >
> > [1]
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
> >
> >
> > Roman
> >
> >
> >> On 03/24/2014 09:04 AM, Roman Haefeli wrote:
> >>> Hi all, Ola
> >>>
> >>> I followed the recent discussion about OpenVZ kernel package management
> >>> for Debian. While I don't really have a qualified opinion on the
> subject
> >>> matter (personally, I slightly tend towards a new package for each
> >>> release), let me mention problems with the current situation:
> >>>
> >>> * 'uname -r' does not print the actual version (This already has
> >>>been mentioned in the other thread)
> >>>
> >>> * If there is a problem with a kernel update, I cannot easily revert
> >>>to the previous version. At our institution, we experienced cases
> >>>where a switch to the previous kernel because of a bug was
> necessary.
> >>>
> >>> * I'm trying to upgrade a machine right now from version 042stab084.26
> >>>to newest 042stab085.17. I do:
> >>>
> >>>$ apt-get update && apt-get dist-upgrade
> >>>
> >>>and I'm prompted with the following dialog:
> >>>
> >>>$  Configuring linux-image-2.6.32-openvz-amd64
> >>>$  ---
> >>>$
> >>>$  You are attempting to install a kernel image (version
> 2.6.32-openvz-amd64) However, the directory
> /lib/modules/2.6.32-openvz-amd64/kernel still exists.  If this directory
> belongs to a previous linux-image-2.6.32-openvz-amd64
> >>>$  package, and if you have deselected some modules, or installed
> standalone modules packages, this could be bad.
> >>>$
> >>>$  If /lib/modules/2.6.32-openvz-amd64/kernel belongs to an old
> install of linux-image-2.6.32-openvz-amd64, then this is your last chance
> to abort the installation of this kernel image (nothing has been changed
> yet).
> >>>$
> >>>$  If you know what you are doing, and if you feel that this image
> should be installed despite this anomaly, Please answer n to the question.
> >>>$
> >>>$  Otherwise, I suggest you move
> /lib/modules/2.6.32-openvz-amd64/kernel out of the way, perhaps to
> /lib/modules/2.6.32-openvz-amd64.kernel.old or something, and then try
> re-installing this image.
> >>>$
> >>>$  Stop install since the kernel-image is already installed?
> >>>
> >>>If Debian does in-place kernel upgrades (a.k.a keeping the package
> >>>name while upgrading the kernel), they managed to never bother the
> >>>user with a question like this. I certainly know too little about
> >>>kernel package management to be of any help,  but to me that dialog
> >>>indicates that something is still odd.
> >>>
> >>>
> >>> Those issues might be solved while sticking to the in-place upgrade
> >>> scheme and are not necessarily an argument against it. I just wa

Re: [Users] Issues with kernel upgrade on Debian Wheezy

[spameden]

2014-03-24 20:04 GMT+04:00 Roman Haefeli :

> Hi all, Ola
>
> I followed the recent discussion about OpenVZ kernel package management
> for Debian. While I don't really have a qualified opinion on the subject
> matter (personally, I slightly tend towards a new package for each
> release), let me mention problems with the current situation:
>
> * 'uname -r' does not print the actual version (This already has
>   been mentioned in the other thread)
>

Yes, I mentioned this before, thought it was fixed already..


>
> * If there is a problem with a kernel update, I cannot easily revert
>   to the previous version. At our institution, we experienced cases
>   where a switch to the previous kernel because of a bug was necessary.
>

+1


>
> * I'm trying to upgrade a machine right now from version 042stab084.26
>   to newest 042stab085.17. I do:
>
>   $ apt-get update && apt-get dist-upgrade
>
>   and I'm prompted with the following dialog:
>
>   $  Configuring linux-image-2.6.32-openvz-amd64
>   $  ---
>   $
>   $  You are attempting to install a kernel image (version
> 2.6.32-openvz-amd64) However, the directory
> /lib/modules/2.6.32-openvz-amd64/kernel still exists.  If this directory
> belongs to a previous linux-image-2.6.32-openvz-amd64
>   $  package, and if you have deselected some modules, or installed
> standalone modules packages, this could be bad.
>   $
>   $  If /lib/modules/2.6.32-openvz-amd64/kernel belongs to an old install
> of linux-image-2.6.32-openvz-amd64, then this is your last chance to abort
> the installation of this kernel image (nothing has been changed yet).
>   $
>   $  If you know what you are doing, and if you feel that this image
> should be installed despite this anomaly, Please answer n to the question.
>   $
>   $  Otherwise, I suggest you move /lib/modules/2.6.32-openvz-amd64/kernel
> out of the way, perhaps to /lib/modules/2.6.32-openvz-amd64.kernel.old or
> something, and then try re-installing this image.
>   $
>   $  Stop install since the kernel-image is already installed?
>

Try removing  linux-image-2.6.32-openvz-amd64 metapackage.. and installing
by fetching speicifc release (e.g. apt-get install
linux-image-2.6.32-openvz-042stab085.17-amd64)

>
>   If Debian does in-place kernel upgrades (a.k.a keeping the package
>   name while upgrading the kernel), they managed to never bother the
>   user with a question like this. I certainly know too little about
>   kernel package management to be of any help,  but to me that dialog
>   indicates that something is still odd.
>
>
> Those issues might be solved while sticking to the in-place upgrade
> scheme and are not necessarily an argument against it. I just wanted to
> mention them.
>

Good point. I think we should stick to the old scheme it was well tested
and was working for nearly everyone.


>
> Ranting aside, I am more than happy to see someone puts the effort into
> making all the great OpenVZ software easily accessible for Debian
> systems. For Debian, the situation has never been better before. Thanks
> a lot for that work.
>
> Roman
>
>
> ___
> 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

Re: [Users] Installation of latest Kernel fails again (deb size mismatch)

[spameden]

2014-03-08 8:27 GMT+04:00 Kir Kolyshkin :

>  On 03/07/2014 06:21 PM, spameden wrote:
>
>  Btw, Kir, there is no version anymore in uname -a.
>
> Could you fix this at least to display current version, e.g. instead of:
>
> # uname -r
> 2.6.32-openvz-amd64
>
>  display:
> # uname -r
> 2.6.32-openvz-042stab084.17-amd64
>
>
> Again, it is the same as in stock Debian kernel. While their version is
> 3.2.54-2,
> uname shows 3.2.0-4.
>

Partly true...

$ uname -a
Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

as you can see there is actual version at the end..


>
>
>
>  and also consider reverting to the old system if you can..
>
>
>
> Yeah, I guess I should do it, just waiting for someone who knows Debian
> more than me to chime in.
>

OK, thanks for the info.

>
>
>
>
> 2014-03-07 18:45 GMT+04:00 Narcis Garcia :
>
>> I think that is a good strategy to have a main package to be manually
>> installed:
>> linux-image-openvz-amd64
>> linux-image-openvz-686
>>
>> But fully versioned as its dependencies (042stab084.26)
>> And with a dependency to a version-named package, such as:
>> linux-image-2.6.32-42.84.26-openvz-amd64
>>
>> In this way, upgrading the main package this will install the new
>> versions of dependencies. I think that this is the way Debian works, and
>> this allows to have old and new files installed simultaneously.
>>
>> To have the old and new kernels allow to test new one before removing
>> old one.
>>
>>
>> El 07/03/14 02:28, Kir Kolyshkin ha escrit:
>> > On 03/02/2014 02:01 PM, spameden wrote:
>> >>
>> >>
>> >>
>>  >> 2014-03-03 0:38 GMT+04:00 Ola Lundqvist >  >> <mailto:o...@inguza.com>>:
>> >>
>> >> Hi
>> >>
>> >> Problem fixed now.
>> >> I had fixed the problem temporarily, but I had forgotten to
>> >> upgrade to the debarchiver version with the fix so it will not
>> >> happen again. Now I have done the upgrade and fixed the problem
>> >> properly.
>> >>
>> >>
>> >> I think it's not fixed properly:
>> >>
>> >> 1) wrong version of linux-image:
>> >> # dpkg -l|grep linux-image-openvz
>> >> ii  linux-image-openvz-amd64
>> >> 042+1 amd64OpenVZ Linux kernel
>> >> (meta-package)
>> >>
>> >> 2) # ls /boot |grep openvz
>> >> config-2.6.32-openvz-042stab084.17-amd64
>>  >> *config-2.6.32-openvz-amd64*
>> >> initrd.img-2.6.32-openvz-042stab084.17-amd64
>> >> *initrd.img-2.6.32-openvz-amd64*
>> >> System.map-2.6.32-openvz-042stab084.17-amd64
>> >> *System.map-2.6.32-openvz-amd64*
>> >> vmlinuz-2.6.32-openvz-042stab084.17-amd64
>> >> *vmlinuz-2.6.32-openvz-amd64*
>> >>
>> >> so now we are missing usual version here in the package.. that's
>> >> actually very bad ... can you look into it?
>> >>
>> >> many thanks.
>> >
>>  > This is intentional, and I changed it after looking into how default
>> > Debian kernel is packaged/versioned.
>> >
>> > If you take a look, they have [meta]package linux-image-amd64 which
>> requires
>> > package linux-image-3.2.0-4-amd64. The latter (currently) has a version
>> of
>> > 3.2.54-2 and this version is changed (incremented) with every release,
>> while
>> > package name stays the same (linux-image-3.2.0-4-amd64). Also, vzkernel
>> > name stays the same -- it is /boot/vmlinuz-3.2.0-4-amd64 in different
>> > versions.
>> > I am using the very same approach now for OpenVZ kernels.
>> >
>>  > Previously I was adding the VZ version (i.e. 042stab0xy.z) into kernel
>> > package name,
>> > and it was added to vmlinuz and the /lib/modules directory name as well.
>>  > The problem
>> > is, you need to specify a different dependency in
>> > linux-image-openvz-amd64 metapackage,
>> > and apt-get upgrade complains that it can't upgrade the system since a
>> > new version
>> > of an installed package (linux-image-amd64) requires a package that is
>> > not installed yet.
>> > The problem could be fixed by running dist-upgrade, but eventually I
>> > decided that
>> > this message is a hint that I package openvz kernels improperly, that
>> > lead me to
>> > looking in

Re: [Users] Installation of latest Kernel fails again (deb size mismatch)

[spameden]

Btw, Kir, there is no version anymore in uname -a.

Could you fix this at least to display current version, e.g. instead of:

# uname -r
2.6.32-openvz-amd64

display:
# uname -r
2.6.32-openvz-042stab084.17-amd64


and also consider reverting to the old system if you can..



2014-03-07 18:45 GMT+04:00 Narcis Garcia :

> I think that is a good strategy to have a main package to be manually
> installed:
> linux-image-openvz-amd64
> linux-image-openvz-686
>
> But fully versioned as its dependencies (042stab084.26)
> And with a dependency to a version-named package, such as:
> linux-image-2.6.32-42.84.26-openvz-amd64
>
> In this way, upgrading the main package this will install the new
> versions of dependencies. I think that this is the way Debian works, and
> this allows to have old and new files installed simultaneously.
>
> To have the old and new kernels allow to test new one before removing
> old one.
>
>
> El 07/03/14 02:28, Kir Kolyshkin ha escrit:
> > On 03/02/2014 02:01 PM, spameden wrote:
> >>
> >>
> >>
> >> 2014-03-03 0:38 GMT+04:00 Ola Lundqvist  >> <mailto:o...@inguza.com>>:
> >>
> >> Hi
> >>
> >> Problem fixed now.
> >> I had fixed the problem temporarily, but I had forgotten to
> >> upgrade to the debarchiver version with the fix so it will not
> >> happen again. Now I have done the upgrade and fixed the problem
> >> properly.
> >>
> >>
> >> I think it's not fixed properly:
> >>
> >> 1) wrong version of linux-image:
> >> # dpkg -l|grep linux-image-openvz
> >> ii  linux-image-openvz-amd64
> >> 042+1 amd64OpenVZ Linux kernel
> >> (meta-package)
> >>
> >> 2) # ls /boot |grep openvz
> >> config-2.6.32-openvz-042stab084.17-amd64
> >> *config-2.6.32-openvz-amd64*
> >> initrd.img-2.6.32-openvz-042stab084.17-amd64
> >> *initrd.img-2.6.32-openvz-amd64*
> >> System.map-2.6.32-openvz-042stab084.17-amd64
> >> *System.map-2.6.32-openvz-amd64*
> >> vmlinuz-2.6.32-openvz-042stab084.17-amd64
> >> *vmlinuz-2.6.32-openvz-amd64*
> >>
> >> so now we are missing usual version here in the package.. that's
> >> actually very bad ... can you look into it?
> >>
> >> many thanks.
> >
> > This is intentional, and I changed it after looking into how default
> > Debian kernel is packaged/versioned.
> >
> > If you take a look, they have [meta]package linux-image-amd64 which
> requires
> > package linux-image-3.2.0-4-amd64. The latter (currently) has a version
> of
> > 3.2.54-2 and this version is changed (incremented) with every release,
> while
> > package name stays the same (linux-image-3.2.0-4-amd64). Also, vzkernel
> > name stays the same -- it is /boot/vmlinuz-3.2.0-4-amd64 in different
> > versions.
> > I am using the very same approach now for OpenVZ kernels.
> >
> > Previously I was adding the VZ version (i.e. 042stab0xy.z) into kernel
> > package name,
> > and it was added to vmlinuz and the /lib/modules directory name as well.
> > The problem
> > is, you need to specify a different dependency in
> > linux-image-openvz-amd64 metapackage,
> > and apt-get upgrade complains that it can't upgrade the system since a
> > new version
> > of an installed package (linux-image-amd64) requires a package that is
> > not installed yet.
> > The problem could be fixed by running dist-upgrade, but eventually I
> > decided that
> > this message is a hint that I package openvz kernels improperly, that
> > lead me to
> > looking into a way standard Debian kernels are packaged and implementing
> it
> > the same way for OpenVZ kernels.
> >
> > I am not a Debian guru and am very open to suggestions on how to improve
> > this.
> > Perhaps we can return to the older versioning scheme and ask people to
> > use dist-upgrade.
> > Or maybe I am totally missing something. Please help.
> >
> > Kir.
> >
> >
> >
> > ___
> > 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
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Installation of latest Kernel fails again (deb size mismatch)

[spameden]

Hi


2014-03-07 5:28 GMT+04:00 Kir Kolyshkin :

>  On 03/02/2014 02:01 PM, spameden wrote:
>
>
>
>
> 2014-03-03 0:38 GMT+04:00 Ola Lundqvist :
>
>> Hi
>>
>>  Problem fixed now.
>> I had fixed the problem temporarily, but I had forgotten to upgrade to
>> the debarchiver version with the fix so it will not happen again. Now I
>> have done the upgrade and fixed the problem properly.
>>
>
>  I think it's not fixed properly:
>
>  1) wrong version of linux-image:
>  # dpkg -l|grep linux-image-openvz
>  ii  linux-image-openvz-amd64
> 042+1 amd64OpenVZ Linux kernel
> (meta-package)
>
>  2) # ls /boot |grep openvz
> config-2.6.32-openvz-042stab084.17-amd64
> *config-2.6.32-openvz-amd64*
> initrd.img-2.6.32-openvz-042stab084.17-amd64
> *initrd.img-2.6.32-openvz-amd64*
> System.map-2.6.32-openvz-042stab084.17-amd64
> *System.map-2.6.32-openvz-amd64*
> vmlinuz-2.6.32-openvz-042stab084.17-amd64
> *vmlinuz-2.6.32-openvz-amd64*
>
>  so now we are missing usual version here in the package.. that's
> actually very bad ... can you look into it?
>
>  many thanks.
>
>
> This is intentional, and I changed it after looking into how default
> Debian kernel is packaged/versioned.
>
> If you take a look, they have [meta]package linux-image-amd64 which
> requires
> package linux-image-3.2.0-4-amd64. The latter (currently) has a version of
> 3.2.54-2 and this version is changed (incremented) with every release,
> while
> package name stays the same (linux-image-3.2.0-4-amd64). Also, vzkernel
> name stays the same -- it is /boot/vmlinuz-3.2.0-4-amd64 in different
> versions.
> I am using the very same approach now for OpenVZ kernels.
>

I understand your position. I checked how it's done in Debian and yes
you're right, they're using this scheme for their mainline 3.2.0-4 kernel.

Tbh, I don't like their "NEW" way at all.

Here is why:

When new version of OpenVZ kernel comes its hard to have 2 different
kernels on the system (with different versions).

Here is a simple scenario:

1) new kernel comes and it's not working at all on certain configurations.

2) if you configured grub correctly it would boot previously working kernel
after reboot.

--> But it wont boot previous OpenVZ kernel version, because when you
upgrade you overwrite existing kernel and you need to rollback to the
previous version manually.


> Previously I was adding the VZ version (i.e. 042stab0xy.z) into kernel
> package name,
> and it was added to vmlinuz and the /lib/modules directory name as well.
>

I really liked how it was done before.  There was an option to leave
certain kernel versions for testing as well and delete what is not needed.


> The problem
> is, you need to specify a different dependency in linux-image-openvz-amd64
> metapackage,
> and apt-get upgrade complains that it can't upgrade the system since a new
> version
> of an installed package (linux-image-amd64) requires a package that is not
> installed yet.
> The problem could be fixed by running dist-upgrade, but eventually I
> decided that
> this message is a hint that I package openvz kernels improperly, that lead
> me to
> looking into a way standard Debian kernels are packaged and implementing it
> the same way for OpenVZ kernels.
>

Interesting.. I never seen myself such problem before. It worked just fine
for me for a long time (before there was a problem with chksums).


> I am not a Debian guru and am very open to suggestions on how to improve
> this.
> Perhaps we can return to the older versioning scheme and ask people to use
> dist-upgrade.
> Or maybe I am totally missing something. Please help.
>

Yes, old way was really cool and convinient personally for me on production
environment. And for testing new stable kernel versions too.

Of course there is a drawback that you need to cleanup old kernel versions
manually, cuz your /boot partition must have some free space for future
upgrades.

If OpenVZ kernels are very well tested before going to stable versions I
wouldnt mind NEW way. It's probably more proper to have just 1 OpenVZ
kernel version and update it from time to time..




>
> Kir.
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Installation of latest Kernel fails again (deb size mismatch)

[spameden]

2014-03-03 2:36 GMT+04:00 Ola Lundqvist :

> Hi "spameded" and Kir
>
> Kir: Something for you below.
>
> The problem with the file size is fixed, right? What I ment with properly
> was to make sure the file size problem is fixed. Nothing else.
>

Yes, it works fine now, thanks!


> However you are right that we have more problems.
>
> 1) The version seems to be a bit odd, yes.
>
> 2) You are right. But I think Kir have to look into this as he was the one
> creating these packages.
>
> The linux-image-openvz-amd64 package depends
> on linux-image-2.6.32-openvz-amd64 which seems to be a image package.
>
linux-image-2.6.32-openvz-amd64 actually contains files from /boot/ with
wrong naming..

package version itself is fine:
ii  linux-image-2.6.32-openvz-amd64
042stab084.26 amd64Linux kernel binary image for
version 2.6.32-openvz-amd64

actually, linux-image-openvz-amd64 is a meta-package for OpenVZ linux
kernel.
it contains changelog & copyright notes, nothing else, but still should be
fixed I guess..


> Cheers,
>
> // Ola
>
>
> Den 2 mar 2014 23:01 skrev "spameden" :
>
>>
>>
>>
>> 2014-03-03 0:38 GMT+04:00 Ola Lundqvist :
>>
>>> Hi
>>>
>>> Problem fixed now.
>>> I had fixed the problem temporarily, but I had forgotten to upgrade to
>>> the debarchiver version with the fix so it will not happen again. Now I
>>> have done the upgrade and fixed the problem properly.
>>>
>>
>> I think it's not fixed properly:
>>
>> 1) wrong version of linux-image:
>> # dpkg -l|grep linux-image-openvz
>> ii  linux-image-openvz-amd64
>> 042+1 amd64OpenVZ Linux kernel
>> (meta-package)
>>
>> 2) # ls /boot |grep openvz
>> config-2.6.32-openvz-042stab084.17-amd64
>> *config-2.6.32-openvz-amd64*
>> initrd.img-2.6.32-openvz-042stab084.17-amd64
>> *initrd.img-2.6.32-openvz-amd64*
>> System.map-2.6.32-openvz-042stab084.17-amd64
>> *System.map-2.6.32-openvz-amd64*
>> vmlinuz-2.6.32-openvz-042stab084.17-amd64
>> *vmlinuz-2.6.32-openvz-amd64*
>>
>> so now we are missing usual version here in the package.. that's actually
>> very bad ... can you look into it?
>>
>> many thanks.
>>
>>
>>
>>> // Ola
>>>
>>>
>>> On Sun, Mar 2, 2014 at 9:02 PM, spameden  wrote:
>>>
>>>> The error is still there:
>>>>
>>>> # aptitude full-upgrade
>>>> The following packages will be upgraded:
>>>>   linux-image-openvz-amd64
>>>> 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>>> Need to get 3,834 B of archives. After unpacking 0 B will be used.
>>>> Do you want to continue? [Y/n/?] y
>>>> Get: 1 http://download.openvz.org/debian/ wheezy/main
>>>> linux-image-openvz-amd64 amd64 042+1 [3,834 B]
>>>> Fetched 3,836 B in 0s (12.2 kB/s)
>>>> E: Failed to fetch
>>>> http://download.openvz.org/debian/dists/wheezy/main/binary-amd64/kernel/linux-image-openvz-amd64_042+1_amd64.deb:
>>>> Size mismatch
>>>>
>>>>
>>>>
>>>> 2014-03-02 21:02 GMT+04:00 Narcis Garcia :
>>>>
>>>>> On 2014-02-27 sure this didn't work right. If this was fixes before,
>>>>> then this means that the problem appeared again.
>>>>>
>>>>>
>>>>> El 02/03/14 17:33, Ola Lundqvist ha escrit:
>>>>>
>>>>> > Hi
>>>>> >
>>>>> > I think I fixed this a couple of days ago. Let me know if it is
>>>>> still a
>>>>> > problem.
>>>>> >
>>>>> > / Ola
>>>>> >
>>>>> > Inguza Technology AB
>>>>> > Sent from a phone
>>>>> >
>>>>> > Den 1 mar 2014 14:39 skrev "spameden" >>>> > <mailto:spame...@gmail.com>>:
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > 2014-03-01 17:01 GMT+04:00 Narcis Garcia >>>> > <mailto:informat...@actiu.net>>:
>>>>>
>>>>> >
>>>>> > To perform the install, I used a cached package from another
>>>>> server.
>>>>> > I suppose the downloadable packages are valid. If not, I can
>>>>> > share my
>>>>&

Re: [Users] Installation of latest Kernel fails again (deb size mismatch)

[spameden]

2014-03-03 0:38 GMT+04:00 Ola Lundqvist :

> Hi
>
> Problem fixed now.
> I had fixed the problem temporarily, but I had forgotten to upgrade to the
> debarchiver version with the fix so it will not happen again. Now I have
> done the upgrade and fixed the problem properly.
>

I think it's not fixed properly:

1) wrong version of linux-image:
# dpkg -l|grep linux-image-openvz
ii  linux-image-openvz-amd64
042+1 amd64OpenVZ Linux kernel
(meta-package)

2) # ls /boot |grep openvz
config-2.6.32-openvz-042stab084.17-amd64
*config-2.6.32-openvz-amd64*
initrd.img-2.6.32-openvz-042stab084.17-amd64
*initrd.img-2.6.32-openvz-amd64*
System.map-2.6.32-openvz-042stab084.17-amd64
*System.map-2.6.32-openvz-amd64*
vmlinuz-2.6.32-openvz-042stab084.17-amd64
*vmlinuz-2.6.32-openvz-amd64*

so now we are missing usual version here in the package.. that's actually
very bad ... can you look into it?

many thanks.



> // Ola
>
>
> On Sun, Mar 2, 2014 at 9:02 PM, spameden  wrote:
>
>> The error is still there:
>>
>> # aptitude full-upgrade
>> The following packages will be upgraded:
>>   linux-image-openvz-amd64
>> 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> Need to get 3,834 B of archives. After unpacking 0 B will be used.
>> Do you want to continue? [Y/n/?] y
>> Get: 1 http://download.openvz.org/debian/ wheezy/main
>> linux-image-openvz-amd64 amd64 042+1 [3,834 B]
>> Fetched 3,836 B in 0s (12.2 kB/s)
>> E: Failed to fetch
>> http://download.openvz.org/debian/dists/wheezy/main/binary-amd64/kernel/linux-image-openvz-amd64_042+1_amd64.deb:
>> Size mismatch
>>
>>
>>
>> 2014-03-02 21:02 GMT+04:00 Narcis Garcia :
>>
>>> On 2014-02-27 sure this didn't work right. If this was fixes before,
>>> then this means that the problem appeared again.
>>>
>>>
>>> El 02/03/14 17:33, Ola Lundqvist ha escrit:
>>>
>>> > Hi
>>> >
>>> > I think I fixed this a couple of days ago. Let me know if it is still a
>>> > problem.
>>> >
>>> > / Ola
>>> >
>>> > Inguza Technology AB
>>> > Sent from a phone
>>> >
>>> > Den 1 mar 2014 14:39 skrev "spameden" >> > <mailto:spame...@gmail.com>>:
>>>
>>> >
>>> >
>>> >
>>> >
>>> > 2014-03-01 17:01 GMT+04:00 Narcis Garcia >> > <mailto:informat...@actiu.net>>:
>>>
>>> >
>>> > To perform the install, I used a cached package from another
>>> server.
>>> > I suppose the downloadable packages are valid. If not, I can
>>> > share my
>>> > cached ones.
>>> >
>>> >
>>> > Thanks for your answer, but I think it should be fixed in the
>>> > repository.
>>> >
>>> > Ola, can you take a look at this please?
>>> >
>>> >
>>> >
>>> >
>>> > El 01/03/14 00:02, spameden ha escrit:
>>> > > I'm having the same thing over here.. Any update on this?
>>> > >
>>> > >
>>> > > 2014-02-27 20:49 GMT+04:00 Narcis Garcia
>>> > mailto:informat...@actiu.net>
>>> > > <mailto:informat...@actiu.net <mailto:informat...@actiu.net
>>> >>>:
>>>
>>> > >
>>> > > *H*ello, I've found this relatively recent thread, that
>>> > seems to be
>>> > > caused by repository tools at server:
>>> > >
>>> >
>>> https://lists.openvz.org/pipermail/users/2014-February/005462.html
>>> > >
>>> > > Because I've the problem again on Debian 7:
>>> > >
>>> > > $ sudo apt-get --install-recommends install
>>> > linux-image-openvz-amd64
>>> > > vzdump ploop
>>> > > Reading package lists... Done
>>> > > Building dependency tree
>>> > > Reading state information... Done
>>> > > The following extra packages will be installed:
>>> > >   cstream libcgroup1 liblockfile-simple-perl
>>> liblog-agent-perl
>>> > > libparted0debian1 libploop1
>>> > linux

Re: [Users] Installation of latest Kernel fails again (deb size mismatch)

[spameden]

The error is still there:

# aptitude full-upgrade
The following packages will be upgraded:
  linux-image-openvz-amd64
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,834 B of archives. After unpacking 0 B will be used.
Do you want to continue? [Y/n/?] y
Get: 1 http://download.openvz.org/debian/ wheezy/main
linux-image-openvz-amd64 amd64 042+1 [3,834 B]
Fetched 3,836 B in 0s (12.2 kB/s)
E: Failed to fetch
http://download.openvz.org/debian/dists/wheezy/main/binary-amd64/kernel/linux-image-openvz-amd64_042+1_amd64.deb:
Size mismatch



2014-03-02 21:02 GMT+04:00 Narcis Garcia :

> On 2014-02-27 sure this didn't work right. If this was fixes before,
> then this means that the problem appeared again.
>
>
> El 02/03/14 17:33, Ola Lundqvist ha escrit:
> > Hi
> >
> > I think I fixed this a couple of days ago. Let me know if it is still a
> > problem.
> >
> > / Ola
> >
> > Inguza Technology AB
> > Sent from a phone
> >
> > Den 1 mar 2014 14:39 skrev "spameden"  > <mailto:spame...@gmail.com>>:
> >
> >
> >
> >
> > 2014-03-01 17:01 GMT+04:00 Narcis Garcia  > <mailto:informat...@actiu.net>>:
> >
> > To perform the install, I used a cached package from another
> server.
> > I suppose the downloadable packages are valid. If not, I can
> > share my
> > cached ones.
> >
> >
> > Thanks for your answer, but I think it should be fixed in the
> > repository.
> >
> > Ola, can you take a look at this please?
> >
> >
> >
> >
> > El 01/03/14 00:02, spameden ha escrit:
> > > I'm having the same thing over here.. Any update on this?
> > >
> > >
> > > 2014-02-27 20:49 GMT+04:00 Narcis Garcia
> > mailto:informat...@actiu.net>
> > > <mailto:informat...@actiu.net <mailto:informat...@actiu.net
> >>>:
> > >
> > > *H*ello, I've found this relatively recent thread, that
> > seems to be
> > > caused by repository tools at server:
> > >
> >
> https://lists.openvz.org/pipermail/users/2014-February/005462.html
> > >
> > > Because I've the problem again on Debian 7:
> > >
> > > $ sudo apt-get --install-recommends install
> > linux-image-openvz-amd64
> > > vzdump ploop
> > > Reading package lists... Done
> > > Building dependency tree
> > > Reading state information... Done
> > > The following extra packages will be installed:
> > >   cstream libcgroup1 liblockfile-simple-perl
> liblog-agent-perl
> > > libparted0debian1 libploop1
> > linux-image-2.6.32-openvz-amd64 parted
> > > rsync vzctl vzquota
> > > Suggested packages:
> > >   libparted0-dev libparted0-i18n fdutils
> > > linux-doc-2.6.32-openvz-amd64
> linux-source-2.6.32-openvz-amd64
> > > ksymoops linux-image-2.6.32-openvz-amd64-dbg parted-doc
> xdelta
> > > kernel-patch-openvz
> > > The following NEW packages will be installed:
> > >   cstream libcgroup1 liblockfile-simple-perl
> liblog-agent-perl
> > > libparted0debian1 libploop1 linux-image-2.6.32-openvz-amd64
> > > linux-image-openvz-amd64 parted ploop rsync vzctl vzdump
> > vzquota
> > > 0 upgraded, 14 newly installed, 0 to remove and 0 not
> > upgraded.
> > > Need to get 45.7 MB of archives.
> > > After this operation, 136 MB of additional disk space will
> > be used.
> > > Do you want to continue [Y/n]? y
> > > Get:1 http://ftp.es.debian.org/debian/ wheezy/main
> > libparted0debian1
> > > amd64 2.3-12 [348 kB]
> > > Get:2 http://download.openvz.org/debian/ wheezy/main
> > > linux-image-2.6.32-openvz-amd64 amd64 042stab084.26 [44.0
> MB]
> > > Get:3 http://ftp.es.debian.org/debian/ wheezy/main parted
> > amd64
> > > 2.3-12 [158 kB]
> > > Get:4 http://ftp.es.debian.org/debian/ wheezy/main cstream
> > amd64
> > > 3.0.0-1 [31.6 kB]
> > &

Re: [Users] Installation of latest Kernel fails again (deb size mismatch)

[spameden]

2014-03-01 17:01 GMT+04:00 Narcis Garcia :

> To perform the install, I used a cached package from another server.
> I suppose the downloadable packages are valid. If not, I can share my
> cached ones.
>

Thanks for your answer, but I think it should be fixed in the repository.

Ola, can you take a look at this please?


>
>
> El 01/03/14 00:02, spameden ha escrit:
> > I'm having the same thing over here.. Any update on this?
> >
> >
> > 2014-02-27 20:49 GMT+04:00 Narcis Garcia  > <mailto:informat...@actiu.net>>:
> >
> > *H*ello, I've found this relatively recent thread, that seems to be
> > caused by repository tools at server:
> > https://lists.openvz.org/pipermail/users/2014-February/005462.html
> >
> > Because I've the problem again on Debian 7:
> >
> > $ sudo apt-get --install-recommends install linux-image-openvz-amd64
> > vzdump ploop
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > The following extra packages will be installed:
> >   cstream libcgroup1 liblockfile-simple-perl liblog-agent-perl
> > libparted0debian1 libploop1 linux-image-2.6.32-openvz-amd64 parted
> > rsync vzctl vzquota
> > Suggested packages:
> >   libparted0-dev libparted0-i18n fdutils
> > linux-doc-2.6.32-openvz-amd64 linux-source-2.6.32-openvz-amd64
> > ksymoops linux-image-2.6.32-openvz-amd64-dbg parted-doc xdelta
> > kernel-patch-openvz
> > The following NEW packages will be installed:
> >   cstream libcgroup1 liblockfile-simple-perl liblog-agent-perl
> > libparted0debian1 libploop1 linux-image-2.6.32-openvz-amd64
> > linux-image-openvz-amd64 parted ploop rsync vzctl vzdump vzquota
> > 0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
> > Need to get 45.7 MB of archives.
> > After this operation, 136 MB of additional disk space will be used.
> > Do you want to continue [Y/n]? y
> > Get:1 http://ftp.es.debian.org/debian/ wheezy/main libparted0debian1
> > amd64 2.3-12 [348 kB]
> > Get:2 http://download.openvz.org/debian/ wheezy/main
> > linux-image-2.6.32-openvz-amd64 amd64 042stab084.26 [44.0 MB]
> > Get:3 http://ftp.es.debian.org/debian/ wheezy/main parted amd64
> > 2.3-12 [158 kB]
> > Get:4 http://ftp.es.debian.org/debian/ wheezy/main cstream amd64
> > 3.0.0-1 [31.6 kB]
> > Get:5 http://ftp.es.debian.org/debian/ wheezy/main liblog-agent-perl
> > all 0.307-2 [128 kB]
> > Get:6 http://ftp.es.debian.org/debian/ wheezy/main
> > liblockfile-simple-perl all 0.208-1 [22.1
> > kB]
> >
> > Get:7 http://ftp.es.debian.org/debian/ wheezy/main rsync amd64
> > 3.0.9-4 [369
> > kB]
> >
> > Get:8 http://ftp.es.debian.org/debian/ wheezy/main libcgroup1 amd64
> > 0.38-1 [43.8
> > kB]
> >
> > Get:9 http://ftp.es.debian.org/debian/ wheezy/main vzquota amd64
> > 3.0.12-3 [92.9
> > kB]
> >
> > Get:10 http://ftp.es.debian.org/debian/ wheezy/main vzdump all
> > 1.2.6-3 [27.8
> > kB]
> >
> > Get:11 http://download.openvz.org/debian/ wheezy/main libploop1
> > amd64 1.10-2 [82.0
> > kB]
> >
> > Get:12 http://download.openvz.org/debian/ wheezy/main vzctl amd64
> > 4.6-1 [330
> > kB]
> >
> > Get:13 http://download.openvz.org/debian/ wheezy/main
> > linux-image-openvz-amd64 amd64 042+1 [3834
> > B]
> >
> > Get:14 http://download.openvz.org/debian/ wheezy/main ploop amd64
> > 1.10-2 [34.0
> > kB]
> >
> > Fetched 45.7 MB in 8min 49s (86.2
> > kB/s)
>
> &
> > nbsp;&nbs p;
> > Failed to fetch
> >
> http://download.openvz.org/debian/dists/wheezy/main/binary-amd64/kernel/linux-image-openvz-amd64_042+1_amd64.deb
> > Size mismatch
> > E: Unable to fetch some archives, maybe run apt-get update or try
> > with --fix-missing?
> >
> >
> >
> >
> > ___
> > Users mailing list
> > Users@openvz.org <mailto:Users@openvz.org>
> > https://lists.openvz.org/mailman/listinfo/users
> >
> >
> >
> >
> > ___
> > 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
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Installation of latest Kernel fails again (deb size mismatch)

[spameden]

I'm having the same thing over here.. Any update on this?


2014-02-27 20:49 GMT+04:00 Narcis Garcia :

>  *H*ello, I've found this relatively recent thread, that seems to be
> caused by repository tools at server:
> https://lists.openvz.org/pipermail/users/2014-February/005462.html
>
> Because I've the problem again on Debian 7:
>
> $ sudo apt-get --install-recommends install linux-image-openvz-amd64
> vzdump ploop
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following extra packages will be installed:
>   cstream libcgroup1 liblockfile-simple-perl liblog-agent-perl
> libparted0debian1 libploop1 linux-image-2.6.32-openvz-amd64 parted rsync
> vzctl vzquota
> Suggested packages:
>   libparted0-dev libparted0-i18n fdutils linux-doc-2.6.32-openvz-amd64
> linux-source-2.6.32-openvz-amd64 ksymoops
> linux-image-2.6.32-openvz-amd64-dbg parted-doc xdelta kernel-patch-openvz
> The following NEW packages will be installed:
>   cstream libcgroup1 liblockfile-simple-perl liblog-agent-perl
> libparted0debian1 libploop1 linux-image-2.6.32-openvz-amd64
> linux-image-openvz-amd64 parted ploop rsync vzctl vzdump vzquota
> 0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
> Need to get 45.7 MB of archives.
> After this operation, 136 MB of additional disk space will be used.
> Do you want to continue [Y/n]? y
> Get:1 http://ftp.es.debian.org/debian/ wheezy/main libparted0debian1
> amd64 2.3-12 [348 kB]
> Get:2 http://download.openvz.org/debian/ wheezy/main
> linux-image-2.6.32-openvz-amd64 amd64 042stab084.26 [44.0 MB]
> Get:3 http://ftp.es.debian.org/debian/ wheezy/main parted amd64 2.3-12
> [158 kB]
> Get:4 http://ftp.es.debian.org/debian/ wheezy/main cstream amd64 3.0.0-1
> [31.6 kB]
> Get:5 http://ftp.es.debian.org/debian/ wheezy/main liblog-agent-perl all
> 0.307-2 [128 kB]
> Get:6 http://ftp.es.debian.org/debian/ wheezy/main
> liblockfile-simple-perl all 0.208-1 [22.1
> kB]
>
> Get:7 http://ftp.es.debian.org/debian/ wheezy/main rsync amd64 3.0.9-4
> [369
> kB]
>
> Get:8 http://ftp.es.debian.org/debian/ wheezy/main libcgroup1 amd64
> 0.38-1 [43.8
> kB]
>
> Get:9 http://ftp.es.debian.org/debian/ wheezy/main vzquota amd64 3.0.12-3
> [92.9
> kB]
>
> Get:10 http://ftp.es.debian.org/debian/ wheezy/main vzdump all 1.2.6-3
> [27.8
> kB]
>
> Get:11 http://download.openvz.org/debian/ wheezy/main libploop1 amd64
> 1.10-2 [82.0
> kB]
>
> Get:12 http://download.openvz.org/debian/ wheezy/main vzctl amd64 4.6-1
> [330
> kB]
>
> Get:13 http://download.openvz.org/debian/ wheezy/main
> linux-image-openvz-amd64 amd64 042+1 [3834
> B]
>
> Get:14 http://download.openvz.org/debian/ wheezy/main ploop amd64 1.10-2
> [34.0
> kB]
>
> Fetched 45.7 MB in 8min 49s (86.2
> kB/s) 
>   
> &
> nbsp;&nbs p;
> Failed to fetch
> http://download.openvz.org/debian/dists/wheezy/main/binary-amd64/kernel/linux-image-openvz-amd64_042+1_amd64.deb
> Size mismatch
> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?
>
>
>
>
> ___
> 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

Re: [Users] IPTABLES on Container

[spameden]

please read this http://openvz.org/Setting_up_an_iptables_firewall


2014-02-27 2:55 GMT+04:00 Matt :

> > I have several bridged containers I need to run iptables on.  I
> > assumed since they were bridged it would just work.  Are there any
> > knobs I must turn to enable iptables on the container?
>
> In vz.conf I have:
>
> ## IPv4 iptables kernel modules to be enabled in CTs by default
> IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter
> iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length"
>
> Do I need anything else in the 101.conf for it to work on that
> container?  I am starting with trying to get the basic IPTABLES config
> below to work inside a container.
>
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent
> --set --name SSH
>
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent
> --update --seconds 60 --hitcount 3 --rttl --name SSH -j LOG
> --log-prefix 'SSH attack: '
>
> iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent
> --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
> ___
> 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

Re: [Users] IPTABLES on Container

[spameden]

2014-02-25 21:46 GMT+04:00 Scott Dowdle :

> Greetings,
>
> - Original Message -
> > I have several bridged containers I need to run iptables on.  I
> > assumed since they were bridged it would just work.  Are there any
> > knobs I must turn to enable iptables on the container?
>
> There are a few wiki pages on iptables stuff.  Have you consulted them.
>
> I haven't used iptables with OpenVZ for quite a while so I'm surely
> rusty... but I think the gist of it is to make sure you have all of the
> needed modules loaded on the host node.  Some distros use different
> kernels... and as a result some of the programs they provide to manage
> iptables may or may not work with the iptables modules provided by your
> host node kernel.
>

Basically, you need this + capability NET_ADMIN turned on.

something like this in /etc/vz/conf/123.conf:

IPTABLES="ip_tables iptable_filter iptable_mangle ipt_limit ipt_multiport
ipt_tos ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ip_conntrack
ipt_state ipt_recent "
CAPABILITY=" NET_ADMIN:on"


> TYL,
> --
> Scott Dowdle
> 704 Church Street
> Belgrade, MT 59714
> (406)388-0827 [home]
> (406)994-3931 [work]
> ___
> 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

[Users] cyrillic / russian symbols in the CT console

[spameden]

hi guys!

i'm using Debian 7 with OpenVZ wheezy kernel from repository.

if i try to type on my HN russian symbols it works just fine.

but if i inter the CN, e.g.:

vzctl enter 

and try to type something in russian language i get garbled output and
questionmarks.

i have set correct LANG variable inside the CT node, what else could be
causing this?
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] venet vs veth

[spameden]

It's completely ok to mix interfaces.

We're using both veth and venet in VNs.

veth we're using for internal shared network between VN and HN (e.g. DNS
server / MySQL).

It's better to create appropriate bridge devices for each group of VN, e.g.:

vzbr100
vzbr200
vzbr300

etc ..

so you add veth100 veth101 veth102 into vzbr100 and they are all in the
same VLAN basically..


2013/11/23 Rene C. 

> i've already been throught
> http://wiki.openvz.org/Differences_between_venet_and_veth - what not
> clear to me, is it ok to mix and match the two network systems on the
> same hardware node?  Any reason not to do this?
>
>
> One of our users need a hwaddr for licensing reasons so I guess we'd
> have to set him up with  veth container right?  Or is there a better
> way?
> ___
> 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

Re: [Users] how to disable suspend / restore?

[spameden]

Thanks, Scott, but I've already replied myself 14 minutes after :)


2013/11/20 Scott Dowdle 

> Greetings,
>
> - Original Message -
> > it seems current vzctl is not handling well suspend / restore
> > procedure (i.e. i'm getting a lot of 502 errors on php5-fpm sites).
> >
> > how can I disable suspend / restore on reboot ? what should I add
> > into container configuration file to do this?
> >
> > (e.g. SUSPEND=OFF in 666.conf or smth?)
>
> There is a global setting in /etc/vz/vz.conf
>
> man vz.conf
>
> Look for VE_STOP_MODE=suspend|stop
>
> TYL,
> --
> Scott Dowdle
> 704 Church Street
> Belgrade, MT 59714
> (406)388-0827 [home]
> (406)994-3931 [work]
> ___
> 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

Re: [Users] how to disable suspend / restore?

[spameden]

nvm, should look more in the manual first before asking :)

there is a global parameter called VE_STOP_MODE=suspend|stop

so just add VE_STOP_MODE=stop into /etc/vz/vz.conf and job is done :)


2013/11/20 spameden 

> it seems current vzctl is not handling well suspend / restore procedure
> (i.e. i'm getting a lot of 502 errors on php5-fpm sites).
>
> how can I disable suspend / restore on reboot ? what should I add into
> container configuration file to do this?
>
> (e.g. SUSPEND=OFF in 666.conf or smth?)
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

[Users] how to disable suspend / restore?

[spameden]

it seems current vzctl is not handling well suspend / restore procedure
(i.e. i'm getting a lot of 502 errors on php5-fpm sites).

how can I disable suspend / restore on reboot ? what should I add into
container configuration file to do this?

(e.g. SUSPEND=OFF in 666.conf or smth?)
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Debian 7 HN Repository

[spameden]

Hi.
> After upgrading now I see that the new kernel appear above so now I have:
> #update-grub
> Generating grub.cfg ...
> Found linux image: /boot/vmlinuz-3.2.0-4-amd64
> Found initrd image: /boot/initrd.img-3.2.0-4-amd64
> Found linux image: /boot/vmlinuz-2.6.32-openvz-042stab081.5-amd64
> Found initrd image: /boot/initrd.img-2.6.32-openvz-042stab081.5-amd64
> Found linux image: /boot/vmlinuz-2.6.32-openvz-042stab081.3-amd64
> Found initrd image: /boot/initrd.img-2.6.32-openvz-042stab081.3-amd64
>
> That means GRUB_DEFAULT=2 doesn't need to be changed to 4 and so on on
> "apt-get upgrade". But it still needs to be changed the first time.

Add these lines to the grub configuration:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT=1

It means grub would save the last working boot option (in case openvz
kernel won't boot).

Also you need to explicitly set the OpenVZ kernel with grub-set-default command.

In your case (if you want to use 2.6.32-openvz-042stab081.5) you need
to execute:

grub-set-default 2

after that do update-grub and reboot, also make sure /vmlinuz and
/initrd.img symlinks point to correct kernel version (in your case
/boot/vmlinuz-2.6.32-openvz-042stab081.5-amd64 and
/boot/initrd.img-2.6.32-openvz-042stab081.5-amd64 respectively).
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Fwd: [Announce] Kernel RHEL6 042stab081.5 (stable)

[spameden]

2013/10/24 Ola Lundqvist :
> Hi
>
> You can use pinning, and you can also use the wheezy-test repository
> temporarily just when installing vzctl and vzquota.

Thanks for your reply, but that didn't solve my question.

Because I do not want to use latest vzctl (testing), I need latest
vzctl from stable OpenVZ repo.

Is it possible to add? I guess I have to do things manually still
(e.g. using alien with fakeroot each time new vzctl released).

Thanks


>
> // Ola
>
>
> On Thu, Oct 24, 2013 at 11:12 AM, CoolCold  wrote:
>>
>> You can use pins to set higher priority for vzctl from OpenVZ repo like
>>
>>Package: vzctl
>>Pin: release a=testing
>>Pin-Priority: 900
>>
>> string "   Pin: release a=testing" can be formed basing on output
>> of
>> #apt-cache policy
>> it will show identification fields for repositories.
>>
>> On Thu, Oct 24, 2013 at 12:09 PM, spameden  wrote:
>> > Sorry, forgot to include users list...
>> >
>> > 2013/10/24 spameden :
>> >> 2013/10/24 Ola Lundqvist :
>> >>> Hi
>> >>>
>> >>> vzctl and vzquota is in Debian wheezy (normal debian, not this
>> >>> repository).
>> >>> The versions in Debian wheezy (stable) should work just fine, no need
>> >>> to
>> >>> upgrade them unless you need ploop support, or have faced some bug
>> >>> that
>> >>> happend to be solved in a later version.
>> >>
>> >> Well, there were some bugs fixed in recent vzctl and I really want to
>> >> use stable version, e.g.
>> >> ii  vzctl   4.5.1-1amd64
>> >>OpenVZ containers control utility
>> >> ii  vzctl-core  4.5.1-1amd64
>> >>OpenVZ containers control utility core
>> >>
>> >>>
>> >>> The latest versions of those tools are in wheezy-test. They are still
>> >>> being
>> >>> tested out to be sure they work fine.
>> >>>
>> >>> Add
>> >>> deb http://download.openvz.org/debian wheezy-test main
>> >>> if you want to try out the latest versions of vzctl and vzquota.
>> >>
>> >> If I add this repository my Debian becomes a mess because kernel I
>> >> will have to use would be from -test repository as well, but I really
>> >> want to use stable release.
>> >>
>> >> Currently I have to build myself vzkernel, vzctl, vzctl-core, vzquota
>> >> from the rpm's, I thought this repository was to "easy things" for
>> >> end-users, so you just type aptitude update && aptitude full-upgrade
>> >> and get recent versions of the stable packages, same as on CentOS.
>> >>
>> >> Is is too much hassle to add vzctl from stable .rpm build to stable
>> >> debian repository (e.g. from this link -
>> >> http://download.openvz.org/current/)  ?
>> >>
>> >> Thanks.
>> >>
>> >>>
>> >>> vzctl-core is part of vzctl in Debian. Kir have to answer about the
>> >>> vzkernel-firmware. I guess it is part of the normal linux-image, but I
>> >>> may
>> >>> be wrong here.
>> >>>
>> >>> There is no strong reason why we keep multiple versions of the kernel.
>> >>> You
>> >>> have the freedom to select an older version. We will clean up old
>> >>> versions
>> >>> later on. This is more because of how the apt archive manager used
>> >>> works,
>> >>> than something else.
>> >>>
>> >>> // Ola
>> >>>
>> >>>
>> >>> On Wed, Oct 23, 2013 at 11:01 PM, spameden  wrote:
>> >>>>
>> >>>> 2013/10/24 Ola Lundqvist :
>> >>>> > Hi Kir
>> >>>> >
>> >>>> > I found the problem. The reason is that linux-image-openvz-amd64
>> >>>> > depends
>> >>>> > on
>> >>>> > linux-image-openvz-042stab081.5-amd64 instead of the real package
>> >>>> > name
>> >>>> > linux-image-2.6.32-openvz-042stab081.5-amd64.
>> >>>> > The string -2.6.32 is missing simply.
>> >>>> >
>> >>>>
>> >>>> Why th

Re: [Users] Fwd: [Announce] Kernel RHEL6 042stab081.5 (stable)

[spameden]

2013/10/24 CoolCold :
> You can use pins to set higher priority for vzctl from OpenVZ repo like
>
>Package: vzctl
>Pin: release a=testing
>Pin-Priority: 900
>
> string "   Pin: release a=testing" can be formed basing on output of
> #apt-cache policy
> it will show identification fields for repositories.

Thanks for your reply, but that didn't solve my question.

Because I do not want to use latest vzctl (testing), I need latest
vzctl from stable OpenVZ repo.

>
> On Thu, Oct 24, 2013 at 12:09 PM, spameden  wrote:
>> Sorry, forgot to include users list...
>>
>> 2013/10/24 spameden :
>>> 2013/10/24 Ola Lundqvist :
>>>> Hi
>>>>
>>>> vzctl and vzquota is in Debian wheezy (normal debian, not this repository).
>>>> The versions in Debian wheezy (stable) should work just fine, no need to
>>>> upgrade them unless you need ploop support, or have faced some bug that
>>>> happend to be solved in a later version.
>>>
>>> Well, there were some bugs fixed in recent vzctl and I really want to
>>> use stable version, e.g.
>>> ii  vzctl   4.5.1-1amd64
>>>OpenVZ containers control utility
>>> ii  vzctl-core  4.5.1-1amd64
>>>OpenVZ containers control utility core
>>>
>>>>
>>>> The latest versions of those tools are in wheezy-test. They are still being
>>>> tested out to be sure they work fine.
>>>>
>>>> Add
>>>> deb http://download.openvz.org/debian wheezy-test main
>>>> if you want to try out the latest versions of vzctl and vzquota.
>>>
>>> If I add this repository my Debian becomes a mess because kernel I
>>> will have to use would be from -test repository as well, but I really
>>> want to use stable release.
>>>
>>> Currently I have to build myself vzkernel, vzctl, vzctl-core, vzquota
>>> from the rpm's, I thought this repository was to "easy things" for
>>> end-users, so you just type aptitude update && aptitude full-upgrade
>>> and get recent versions of the stable packages, same as on CentOS.
>>>
>>> Is is too much hassle to add vzctl from stable .rpm build to stable
>>> debian repository (e.g. from this link -
>>> http://download.openvz.org/current/)  ?
>>>
>>> Thanks.
>>>
>>>>
>>>> vzctl-core is part of vzctl in Debian. Kir have to answer about the
>>>> vzkernel-firmware. I guess it is part of the normal linux-image, but I may
>>>> be wrong here.
>>>>
>>>> There is no strong reason why we keep multiple versions of the kernel. You
>>>> have the freedom to select an older version. We will clean up old versions
>>>> later on. This is more because of how the apt archive manager used works,
>>>> than something else.
>>>>
>>>> // Ola
>>>>
>>>>
>>>> On Wed, Oct 23, 2013 at 11:01 PM, spameden  wrote:
>>>>>
>>>>> 2013/10/24 Ola Lundqvist :
>>>>> > Hi Kir
>>>>> >
>>>>> > I found the problem. The reason is that linux-image-openvz-amd64 depends
>>>>> > on
>>>>> > linux-image-openvz-042stab081.5-amd64 instead of the real package name
>>>>> > linux-image-2.6.32-openvz-042stab081.5-amd64.
>>>>> > The string -2.6.32 is missing simply.
>>>>> >
>>>>>
>>>>> Why there is multiple versions of the kernel?
>>>>> p   linux-image-2.6.32-042stab079.5
>>>>>  - Linux kernel binary image for version 2.6.32-042stab079.5
>>>>> p   linux-image-2.6.32-042stab079.6
>>>>>  - Linux kernel binary image for version 2.6.32-042stab079.6
>>>>> p   linux-image-2.6.32-openvz-042stab081.3-amd64
>>>>>  - Linux kernel binary image for version
>>>>> 2.6.32-openvz-042stab081.3-amd64
>>>>> p   linux-image-2.6.32-openvz-042stab081.5-amd64
>>>>>  - Linux kernel binary image for version
>>>>> 2.6.32-openvz-042stab081.5-amd64
>>>>>
>>>>> Instead of one.
>>>>>
>>>>> And can you add vzctl, vzctl-core, vzquota and vzkernel-firmware ?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> >

Re: [Users] Fwd: [Announce] Kernel RHEL6 042stab081.5 (stable)

[spameden]

Sorry, forgot to include users list...

2013/10/24 spameden :
> 2013/10/24 Ola Lundqvist :
>> Hi
>>
>> vzctl and vzquota is in Debian wheezy (normal debian, not this repository).
>> The versions in Debian wheezy (stable) should work just fine, no need to
>> upgrade them unless you need ploop support, or have faced some bug that
>> happend to be solved in a later version.
>
> Well, there were some bugs fixed in recent vzctl and I really want to
> use stable version, e.g.
> ii  vzctl   4.5.1-1amd64
>OpenVZ containers control utility
> ii  vzctl-core  4.5.1-1amd64
>OpenVZ containers control utility core
>
>>
>> The latest versions of those tools are in wheezy-test. They are still being
>> tested out to be sure they work fine.
>>
>> Add
>> deb http://download.openvz.org/debian wheezy-test main
>> if you want to try out the latest versions of vzctl and vzquota.
>
> If I add this repository my Debian becomes a mess because kernel I
> will have to use would be from -test repository as well, but I really
> want to use stable release.
>
> Currently I have to build myself vzkernel, vzctl, vzctl-core, vzquota
> from the rpm's, I thought this repository was to "easy things" for
> end-users, so you just type aptitude update && aptitude full-upgrade
> and get recent versions of the stable packages, same as on CentOS.
>
> Is is too much hassle to add vzctl from stable .rpm build to stable
> debian repository (e.g. from this link -
> http://download.openvz.org/current/)  ?
>
> Thanks.
>
>>
>> vzctl-core is part of vzctl in Debian. Kir have to answer about the
>> vzkernel-firmware. I guess it is part of the normal linux-image, but I may
>> be wrong here.
>>
>> There is no strong reason why we keep multiple versions of the kernel. You
>> have the freedom to select an older version. We will clean up old versions
>> later on. This is more because of how the apt archive manager used works,
>> than something else.
>>
>> // Ola
>>
>>
>> On Wed, Oct 23, 2013 at 11:01 PM, spameden  wrote:
>>>
>>> 2013/10/24 Ola Lundqvist :
>>> > Hi Kir
>>> >
>>> > I found the problem. The reason is that linux-image-openvz-amd64 depends
>>> > on
>>> > linux-image-openvz-042stab081.5-amd64 instead of the real package name
>>> > linux-image-2.6.32-openvz-042stab081.5-amd64.
>>> > The string -2.6.32 is missing simply.
>>> >
>>>
>>> Why there is multiple versions of the kernel?
>>> p   linux-image-2.6.32-042stab079.5
>>>  - Linux kernel binary image for version 2.6.32-042stab079.5
>>> p   linux-image-2.6.32-042stab079.6
>>>  - Linux kernel binary image for version 2.6.32-042stab079.6
>>> p   linux-image-2.6.32-openvz-042stab081.3-amd64
>>>  - Linux kernel binary image for version
>>> 2.6.32-openvz-042stab081.3-amd64
>>> p   linux-image-2.6.32-openvz-042stab081.5-amd64
>>>  - Linux kernel binary image for version
>>> 2.6.32-openvz-042stab081.5-amd64
>>>
>>> Instead of one.
>>>
>>> And can you add vzctl, vzctl-core, vzquota and vzkernel-firmware ?
>>>
>>> Thanks.
>>>
>>>
>>> > // Ola
>>> >
>>> >
>>> > On Wed, Oct 23, 2013 at 10:44 PM, Ola Lundqvist  wrote:
>>> >>
>>> >> Hi
>>> >>
>>> >> This looks a bit odd. I'll look into this.
>>> >>
>>> >> Could you send me the output of
>>> >> COLUMNS=180 dpkg -l "linux-image*"
>>> >>
>>> >> And just checking.
>>> >> You did an
>>> >> apt-get update
>>> >> before
>>> >> apt-get dist-upgrade
>>> >> right?
>>> >>
>>> >> The reason why apt-get upgrade holds the package back is that it needs
>>> >> one
>>> >> more package. This is why you should use dist-upgrade in these cases.
>>> >> But I
>>> >> guess you already know that.
>>> >>
>>> >> // Ola
>>> >>
>>> >>
>>> >> On Wed, Oct 23, 2013 at 10:07 PM, Kir Kolyshkin  wrote:
>>> >>>
>>> >>> On 10/23/2013 11:58 AM, Johan Wilfer wrote:
>>> >>>>
>>> >>>> 2013-10-23 18:29, Kir Ko

Re: [Users] Fwd: [Announce] Kernel RHEL6 042stab081.5 (stable)

[spameden]

2013/10/24 Ola Lundqvist :
> Hi Kir
>
> I found the problem. The reason is that linux-image-openvz-amd64 depends on
> linux-image-openvz-042stab081.5-amd64 instead of the real package name
> linux-image-2.6.32-openvz-042stab081.5-amd64.
> The string -2.6.32 is missing simply.
>

Why there is multiple versions of the kernel?
p   linux-image-2.6.32-042stab079.5
 - Linux kernel binary image for version 2.6.32-042stab079.5
p   linux-image-2.6.32-042stab079.6
 - Linux kernel binary image for version 2.6.32-042stab079.6
p   linux-image-2.6.32-openvz-042stab081.3-amd64
 - Linux kernel binary image for version
2.6.32-openvz-042stab081.3-amd64
p   linux-image-2.6.32-openvz-042stab081.5-amd64
 - Linux kernel binary image for version
2.6.32-openvz-042stab081.5-amd64

Instead of one.

And can you add vzctl, vzctl-core, vzquota and vzkernel-firmware ?

Thanks.


> // Ola
>
>
> On Wed, Oct 23, 2013 at 10:44 PM, Ola Lundqvist  wrote:
>>
>> Hi
>>
>> This looks a bit odd. I'll look into this.
>>
>> Could you send me the output of
>> COLUMNS=180 dpkg -l "linux-image*"
>>
>> And just checking.
>> You did an
>> apt-get update
>> before
>> apt-get dist-upgrade
>> right?
>>
>> The reason why apt-get upgrade holds the package back is that it needs one
>> more package. This is why you should use dist-upgrade in these cases. But I
>> guess you already know that.
>>
>> // Ola
>>
>>
>> On Wed, Oct 23, 2013 at 10:07 PM, Kir Kolyshkin  wrote:
>>>
>>> On 10/23/2013 11:58 AM, Johan Wilfer wrote:

 2013-10-23 18:29, Kir Kolyshkin skrev:
>
> On 10/23/2013 05:30 AM, Johan Wilfer wrote:
>>
>> Any suggestions?
>
>
> Unfortunately you have not provided enough information.
> What repos are configured? What kernel(s) are installed?


 Sorry for that:

 /etc/apt/sources.list:
 # openvz - stable
 deb http://download.openvz.org/debian wheezy main

 #uname -a
 Linux microhn01 2.6.32-openvz-042stab081.3-amd64 #1 SMP Mon Sep 9
 19:56:43 MSK 2013 x86_64 GNU/Linux

 installed package is "linux-image-openvz-amd64"..
>>>
>>>
>>> Thanks, this looks correct. Have you tried doing "apt-get install
>>> linux-image-openvz-amd64"?
>>>
>>> Frankly speaking, I am not that good at debian package management,
>>> so I have added a couple of folks to Cc who might know better.
>>>
>>> Kir.
>>>

>
>>
>> /Johan
>>
>> 2013-10-15 21:05, Johan Wilfer skrev:
>>>
>>> Hi,
>>>
>>> If I try upgrading from the previous kernel (meta-package
>>> linux-image-openvz-amd64) on Debian with the repro at
>>> download.openvz.org/debian I get this:
>>>
>>>
>>> # apt-get update
>>> 
>>>
>>> # apt-get upgrade
>>> Reading package lists... Done
>>> Building dependency tree
>>> Reading state information... Done
>>> Calculating upgrade... Done
>>> The following packages have been kept back:
>>>linux-image-openvz-amd64
>>> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>>>
>>> # apt-get dist-upgrade
>>> Reading package lists... Done
>>> Building dependency tree
>>> Reading state information... Done
>>> Calculating upgrade... Done
>>> The following packages have been kept back:
>>>linux-image-openvz-amd64
>>> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>>>
>>> ???
>>>
>>> /Johan
>>>
>>>
>>>  Ursprungligt meddelande 
>>> Ämne: [Announce] Kernel RHEL6 042stab081.5 (stable)
>>> Datum: Tue, 15 Oct 2013 11:14:17 -0700
>>> Från: Kir Kolyshkin 
>>> Organisation: OpenVZ
>>> Till: annou...@openvz.org 
>>>
>>>
>>> OpenVZ project released an updated RHEL6 based kernel. Read below for
>>> more information. Everyone is advised to upgrade.

 ___
 Users mailing list
 Users@openvz.org
 https://lists.openvz.org/mailman/listinfo/users
>>>
>>>
>>
>>
>>
>> --
>>  --- Inguza Technology AB --- MSc in Information Technology 
>> /  o...@inguza.comAnnebergsslingan 37\
>> |  o...@debian.org   654 65 KARLSTAD|
>> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>>  ---
>>
>
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comAnnebergsslingan 37\
> |  o...@debian.org   654 65 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---
>
>
> ___
> Users mailing list
> Users@openvz.org
> https:

Re: [Users] Fwd: [Announce] Kernel RHEL6 042stab081.5 (stable)

[spameden]

Guys, you didn't add vzctl and vzquota utils to the stable distro of
Debian's repo for wheezy.

Please, could you add them?

And for some reason there are multiple versions of kernel:

# aptitude search '~O"Openvz"'
p   linux-headers-2.6.32-042stab079.6
 - Header files related to Linux kernel, specifically,
p   linux-headers-2.6.32-openvz-042stab081.3-amd64
 - Header files related to Linux kernel, specifically,
p   linux-headers-2.6.32-openvz-042stab081.5-amd64
 - Header files related to Linux kernel, specifically,
p   linux-image-2.6.32-042stab079.5
 - Linux kernel binary image for version 2.6.32-042stab079.5
p   linux-image-2.6.32-042stab079.6
 - Linux kernel binary image for version 2.6.32-042stab079.6
p   linux-image-2.6.32-openvz-042stab081.3-amd64
 - Linux kernel binary image for version
2.6.32-openvz-042stab081.3-amd64
p   linux-image-2.6.32-openvz-042stab081.5-amd64
 - Linux kernel binary image for version
2.6.32-openvz-042stab081.5-amd64
p   linux-image-openvz-amd64
 - OpenVZ Linux kernel (meta-package)
p   linux-source-2.6.32-openvz-042stab081.3-amd64
 - Linux kernel source for version
2.6.32-openvz-042stab081.3-amd64
p   linux-source-2.6.32-openvz-042stab081.5-amd64
 - Linux kernel source for version
2.6.32-openvz-042stab081.5-amd64
p   vzstats
 - OpenVZ component to gather statistics to improve the
project

I've just added one line to the /etc/apt/sources.list.d/openvz.list on
the fresh Debian Wheezy system:

deb http://download.openvz.org/debian wheezy main

Many thanks.


2013/10/24 Kir Kolyshkin :
> On 10/23/2013 11:58 AM, Johan Wilfer wrote:
>>
>> 2013-10-23 18:29, Kir Kolyshkin skrev:
>>>
>>> On 10/23/2013 05:30 AM, Johan Wilfer wrote:

 Any suggestions?
>>>
>>>
>>> Unfortunately you have not provided enough information.
>>> What repos are configured? What kernel(s) are installed?
>>
>>
>> Sorry for that:
>>
>> /etc/apt/sources.list:
>> # openvz - stable
>> deb http://download.openvz.org/debian wheezy main
>>
>> #uname -a
>> Linux microhn01 2.6.32-openvz-042stab081.3-amd64 #1 SMP Mon Sep 9 19:56:43
>> MSK 2013 x86_64 GNU/Linux
>>
>> installed package is "linux-image-openvz-amd64"..
>
>
> Thanks, this looks correct. Have you tried doing "apt-get install
> linux-image-openvz-amd64"?
>
> Frankly speaking, I am not that good at debian package management,
> so I have added a couple of folks to Cc who might know better.
>
> Kir.
>
>
>>
>>>

 /Johan

 2013-10-15 21:05, Johan Wilfer skrev:
>
> Hi,
>
> If I try upgrading from the previous kernel (meta-package
> linux-image-openvz-amd64) on Debian with the repro at
> download.openvz.org/debian I get this:
>
>
> # apt-get update
> 
>
> # apt-get upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages have been kept back:
>linux-image-openvz-amd64
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>
> # apt-get dist-upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages have been kept back:
>linux-image-openvz-amd64
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>
> ???
>
> /Johan
>
>
>  Ursprungligt meddelande 
> Ämne: [Announce] Kernel RHEL6 042stab081.5 (stable)
> Datum: Tue, 15 Oct 2013 11:14:17 -0700
> Från: Kir Kolyshkin 
> Organisation: OpenVZ
> Till: annou...@openvz.org 
>
> OpenVZ project released an updated RHEL6 based kernel. Read below for
> more information. Everyone is advised to upgrade.
>>
>> ___
>> 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

___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Fwd: [Announce] Kernel RHEL6 042stab081.5 (stable)

[spameden]

 Would be good to add vzctl vztools* to debian stable's repository.

2013/10/15 Johan Wilfer :
> Hi,
>
> If I try upgrading from the previous kernel (meta-package
> linux-image-openvz-amd64) on Debian with the repro at
> download.openvz.org/debian I get this:
>
>
> # apt-get update
> 
>
> # apt-get upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages have been kept back:
>   linux-image-openvz-amd64
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>
> # apt-get dist-upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages have been kept back:
>   linux-image-openvz-amd64
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>
> ???
>
> /Johan
>
>
>  Ursprungligt meddelande 
> Ämne: [Announce] Kernel RHEL6 042stab081.5 (stable)
> Datum: Tue, 15 Oct 2013 11:14:17 -0700
> Från: Kir Kolyshkin 
> Organisation: OpenVZ
> Till: annou...@openvz.org 
>
>
> OpenVZ project released an updated RHEL6 based kernel. Read below for
> more information. Everyone is advised to upgrade.
>
>
> Changes
> ===
> Since 042stab081.3:
>
> * fs: plug false-positive lockdep splash about sb_writers recursion
> (PCLIN-31921)
> * fs/lockdep: implement recoursive rw transactions properly (PCLIN-32055)
> * ploop: fix FIFREEZE ioctl (PSBM-22372)
>
>
> Download
> 
> http://wiki.openvz.org/Download/kernel/rhel6/042stab081.5
>
>
> Bug reporting
> =
> Use http://bugzilla.openvz.org/  to report any bugs found.
>
>
> Other sources of info on updates
> 
> See http://wiki.openvz.org/News  to view all the news (including updates)
> online. There you can also find RSS/Atom feed links.
>
>
> Best regards,
>   OpenVZ team.
>
>
> ___
> 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

Re: [Users] openvz wiki users

[spameden]

there are some guidelines: http://www.mediawiki.org/wiki/Manual:Combating_spam

should help in most cases.

require captcha on registration / login page and require confirmation
of the e-mail upon registration.

2013/10/15 Kir Kolyshkin :
> On 10/14/2013 06:41 AM, Martin Maurer wrote:
>
> Hi,
>
>
>
> looks like there are some robots active here, trying to spam the pages.?
>
> https://openvz.org/w/index.php?title=Special:ListUsers&dir=prev&username=&group=&creationSort=1
>
>
> Right (and the captcha doesn't help). Fortunately, we found a way for such
> users
> to prevent spamming the wiki, but can't find a way to prevent registering.
>
> If anyone has anti-spam experience with mediawiki, feel free to drop me a
> note.
>
> ___
> 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

Re: [Users] Debian 7 HN Repository

[spameden]

Would be nice to get packages automatically updated for debian as soon
as new stable/testing branch pushed.

Is it possible at all?

2013/10/8 Kir Kolyshkin :
> On 10/08/2013 07:54 AM, Johan Wilfer wrote:
>>
>> 2013-10-06 16:20, Johan Wilfer skrev:
>>>
>>> 2013-10-04 23:12, Kir Kolyshkin skrev:

 On 10/04/2013 01:38 PM, Johan Wilfer wrote:
>
> 2013-10-04 20:52, Kir Kolyshkin skrev:
>>
>> There is a better way now! We have native Debian Wheezy builds
>> for kernel and tools, available at http://download.openvz.org/debian
>> (please see that page for more info). That stuff is still in beta, so
>> if you can test it and report possible bugs back to us that would
>> be just great.
>
> After that I tried to install the package "linux-image-openvz-amd64"
> as a replacement, but I got a package-error (this is from my memory so
> I hope I'm not confusing it with another package now):


 This is the bug I fixed just yesterday, so it should work now. Sorry for
 the problem.

>>>
>>> So "linux-image-openvz-amd64" is the meta-package you should install in
>>> debian to get OpenVZ and not "vzkernel"?
>>>
>>> Because "vzkernel" is mentioned on the tutorials I found.
>>>
>>> Maybe the following text could be added to
>>> http://download.openvz.org/debian?
>>>
>>> "To install the kernel for OpenVZ:
>>> apt-get install linux-image-openvz-amd64"
>>>
>>> Also, just looking at the package-files at:
>>> http://download.openvz.org/debian/dists/wheezy/main/binary-i386/Packages
>>> There seems like no "linux-image-openvz-i386"-package exists?
>>>
>>> And these kernels seems old:
>>> http://download.openvz.org/debian/dists/wheezy/main/binary-i386/alien/
>>>
>>> I only use 64 bit OS for myself, but this is maybe another bug?
>>>
>>> Sorry for complaining.. And THANKS for providing this repository!
>>>
>>
>> Hi!
>>
>> I did try this right now for a fresh system. Seems to still be a broken
>> package?
>>
>> # apt-get install linux-image-openvz-amd64
>>
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>>  linux-image-openvz-amd64 : Depends: linux-image-openvz-042stab081.3-amd64
>> but it is not installable
>> E: Unable to correct problems, you have held broken packages.
>>
>>
> The problem is updated package has the same version as the original one,
> which is not handled by apt. I have uploaded the package with the updated
> release field now, please try again (don't forget apt-get update).
>
> As for wheezy-test, a new kernel will be uploaded soon.
>
> ___
> 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

Re: [Users] DEVNODES-statement does not create devices in directories anymore but in the root at VE /dev

[spameden]

2013/10/4 Kir Kolyshkin :
> On 10/04/2013 01:50 AM, Johan Wilfer wrote:
>>
>> Hi,
>>
>> I am evaluating how to migrate my Debian 6 HN's now when support soon will
>> be dropped for Debian 6 and they also drop official support for Openvz.
>>
>> Right now I testing a Debian 7, with a RHEL-kernel:
>> 2.6.32-openvz-042stab081.3-amd64 with vzctl version 4.5.1
>>
>> They are converted from rpm with alien and installed with dpkg. As
>> instructed here on page 1:
>> http://www.howtoforge.com/installing-and-using-openvz-on-debian-wheezy-amd64
>
>
> There is a better way now! We have native Debian Wheezy builds
> for kernel and tools, available at http://download.openvz.org/debian
> (please see that page for more info). That stuff is still in beta, so
> if you can test it and report possible bugs back to us that would
> be just great.

wow, that's great news! hopefully it would be maintained for a long time!

big up!

will test this one for sure in my dev/production environments.

>
>
>>
>> I've noticed that when I create a VE with DEVNODES-statement, like this:
>> DEVNODES="dahdi/channel:rw dahdi/ctl:rw dahdi/pseudo:rw dahdi/timer:rw"
>>
>> The devices end up in the containers /dev directly, like this (I removed
>> the other devices for clarity):
>> root@test:/dev# ls -la
>> crw-rT  1 root root 196, 254 Oct  3 23:34 channel
>> crw-rT  1 root root 196,   0 Oct  3 23:34 ctl
>> crw-rT  1 root root 196, 255 Oct  3 23:34 pseudo
>> crw-rT  1 root root 196, 253 Oct  3 23:34 timer
>>
>> This is how it looks like on the HN
>> root@microhn01:/dev# ls -la /dev/dahdi/
>> drwxr-xr-x  2 root root  120 okt  3 22:08 .
>> drwxr-xr-x 19 root root 6600 okt  3 22:08 ..
>> crw-rw---T  1 root root 196, 254 okt  3 22:08 channel
>> crw-rw---T  1 root root 196,   0 okt  3 22:08 ctl
>> crw-rw---T  1 root root 196, 255 okt  3 22:08 pseudo
>> crw-rw---T  1 root root 196, 253 okt  3 22:08 timer
>>
>> In OpenVZ on Debian 6 the parent dir "dahdi" was created in the VE, now
>> with this more recent kernel and vzctl all end up in /dev without the
>> dahdi-directory.
>>
>> I can move them myself to /dev/dahdi in the VE, but the reappear in the
>> /dev-dir after restating the VE.
>>
>> It seems to be the same with other devices, like /dev/net/* or /dev/usb/*
>> etc.
>>
>> Any thoughts?

I'm also using Debian Wheezy with Centos RHEL 6 kernel converted by
fakeroot and the only thing I noticed is:

https://bugzilla.openvz.org/show_bug.cgi?id=2675

any update on this one?

sorry if this is a wrong thread to ask.


>
>
> Most probably it has to do something with what distro you have inside a
> container
> rather than the kernel and vzctl.
>
> I tried to reproduce your issue using vzctl-4.5.1 and kernel
> 2.6.32-042stab082.3,
> with a container running centos-6-x86 template, and it works as it should
> (well, almost -- see below):
>
> [HOST] # ls -l /dev/cpu/microcode
> crw-rw 1 root root 10, 184 Oct  3 03:10 /dev/cpu/microcode
>
> [HOST] # vzctl set 1018 --devnodes cpu/microcode:r --save
> Setting devices
> CT configuration saved to /etc/vz/conf/1018.conf
>
> [HOST] # vzctl enter 1018
> entered into CT 1018
>
> [CT] # ls -l /dev/cpu/microcode
> crw--- 1 root root 10, 184 Oct  4 14:42 /dev/cpu/microcode
>
> [CT] # logout
>
> [HOST] # vzctl restart 1018
> 
>
> [root@dhcp-10-30-21-127 ~]# vzctl exec 1018 ls -l /dev/microcode
> crw-r- 1 root root 10, 184 Oct  4 14:43 /dev/microcode
>
> [root@dhcp-10-30-21-127 ~]# vzctl exec 1018 ls -l /dev/cpu/microcode
> crw-rw 1 root root 10, 184 Oct  4 14:43 /dev/cpu/microcode
>
> I am not sure why that happens, but it doesn't look like a big issue to me.
>
> I re-did the same test with the debian-7-x86_64 template, with the
> same results.
>
> Generally, such requests better to be filed as bugs to bugzilla (but for
> this one,
> so far, WORKSFORME).
>
> Kir.
>
>
> ___
> 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

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

Hi

The problem seems to be fixed in 2.6.32-358.18.1.el6.centos.plus.x86_64

Finally found how to install it properly on Debian 7.

Here is results:
# hdparm -t /dev/mapper/vg-root

/dev/mapper/vg-root:
 Timing buffered disk reads: 992 MB in  3.00 seconds = 330.13 MB/sec


Much better as you can see.

How long it would take to get that fix into OpenVZ kernel?

Bug link: http://bugs.centos.org/view.php?id=6548

Kernel:
http://ftp.tu-chemnitz.de/pub/linux/centos/6.4/centosplus/x86_64/Packages/kernel-2.6.32-358.18.1.el6.centos.plus.x86_64.rpm


2013/8/29 spameden 

>
>
>
> 2013/8/29 Kirill Korotaev 
>
>> SSDSC2CW240A3 == Intel 520. It's not server grade as well and though it
>> behaves much much better then desktop SSDs - we still saw it's loosing
>> commits on power failure. So beware that your database can corrupt or loose
>> transactions.
>> All server grade SSDs from Intel have "Enhanced power-loss data
>> protection" feature in specs which implies capacitors on the board for
>> saving data to NVRAM. It's 320, 710 and S3700 models.
>> Intel S3700 is the best and fastest we ever saw among different models
>> including non-Intel ones and this is what Parallels recommends in Parallels
>> Cloud Storage.
>>
>
> Ofc it's not that good, but we can't offer right now to buy overpriced
> hardware (for us, at least).
>
> Our database is XtraDB and it's commiting every second.
>
> Losing 1 second of transactions is not a problem for us.
>
> However, slow speed with 2.6.32 openvz kernel is a problem. As you can see
> there is a problem on this particular kernel.
>
> I'll try to investigate more and report back.
>
>>
>>
>>
>> On Aug 29, 2013, at 13:20 , spameden 
>>  wrote:
>>
>>
>>
>>
>> 2013/8/29 Kirill Korotaev 
>>
>>> I also want to add that SSD models referred to in  the bug (like OCZ
>>> one) are not server grade and you guys risk very much loosing your data or
>>> corrupting file system on power failure.
>>> You should test it heavily.
>>>
>>
>> Thanks for that.
>>
>> But we are not using OCZ (also know they are not reliable).
>>
>> The SSD in this server is INTEL SSDSC2CW240A3.
>>
>> I can't try the latest redhat kernel on this system, because after
>> converting it to deb it seems to be not working.
>>
>> But I believe fix should be in 2.6.32-358.18.1.el6.centos.plus.x86_64.
>>
>>>
>>> On Aug 29, 2013, at 03:52 , Kir Kolyshkin  wrote:
>>>
>>>  On 08/28/2013 06:34 AM, spameden wrote:
>>>
>>>
>>>
>>>
>>> 2013/8/28 Kir Kolyshkin 
>>>
>>>>  On 08/27/2013 08:20 AM, spameden wrote:
>>>>
>>>>  ArchLinux wiki says:
>>>> *Warning: *Users need to be certain that kernel version 2.6.33 or
>>>> above is being used AND that their SSD supports TRIM before attempting to
>>>> mount a partition with the discard flag. Data loss can occur otherwise!
>>>>
>>>>  So I guess it's not in the OpenVZ kernel?
>>>>
>>>> I'd like to use TRIM because it increases performance to SSD
>>>> drastically!
>>>>
>>>>
>>>>  You'd better check it with Red Hat, looking into their RHEL6
>>>> documentation.
>>>>
>>>> My quick googling for "rhel6 kernel ssd discard" shows that rhel6 kernel
>>>> do support trim, they have backported it (as well as tons of other
>>>> stuff,
>>>> so this is hardly 2.6.32 kernel anymore).
>>>>
>>>
>>>  I've just tested via hdparm (ofc it's not a perfect tool to test out
>>> disk performance but still), here is what I get on the latest
>>> 2.6.32-042stab079.5:
>>>
>>> # hdparm -t /dev/mapper/vg-root
>>> /dev/mapper/vg-root:
>>>  Timing buffered disk reads: 828 MB in  3.00 seconds = 275.56 MB/sec
>>>
>>>  on standard debian-7 kernel (3.2.0-4-amd64):
>>> # hdparm -t /dev/mapper/vg-root
>>> /dev/mapper/vg-root:
>>>  Timing buffered disk reads: 1144 MB in  3.00 seconds = 381.15 MB/sec
>>>
>>>  and it's only read speed test.
>>>
>>>  I don't get why it differs so much?
>>>
>>>
>>> My suggestion is, since this functionality is not directly related to
>>> OpenVZ, and
>>> we usually don't change anything in this code (unless there is a reason
>>> to), to
>>> try reproducing it on a stock RHEL6 kernel and, if it is reproducible,
>>> file a bug
>>> to red hat or, if it's not reproducible, file a bug to openvz.
>>>
>>> Kir.
>>>  ___
>>> 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
>>>
>>>
>> ___
>> 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
>>
>>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

2013/8/29 Kirill Korotaev 

> SSDSC2CW240A3 == Intel 520. It's not server grade as well and though it
> behaves much much better then desktop SSDs - we still saw it's loosing
> commits on power failure. So beware that your database can corrupt or loose
> transactions.
> All server grade SSDs from Intel have "Enhanced power-loss data
> protection" feature in specs which implies capacitors on the board for
> saving data to NVRAM. It's 320, 710 and S3700 models.
> Intel S3700 is the best and fastest we ever saw among different models
> including non-Intel ones and this is what Parallels recommends in Parallels
> Cloud Storage.
>

Ofc it's not that good, but we can't offer right now to buy overpriced
hardware (for us, at least).

Our database is XtraDB and it's commiting every second.

Losing 1 second of transactions is not a problem for us.

However, slow speed with 2.6.32 openvz kernel is a problem. As you can see
there is a problem on this particular kernel.

I'll try to investigate more and report back.

>
>
>
> On Aug 29, 2013, at 13:20 , spameden 
>  wrote:
>
>
>
>
> 2013/8/29 Kirill Korotaev 
>
>> I also want to add that SSD models referred to in  the bug (like OCZ one)
>> are not server grade and you guys risk very much loosing your data or
>> corrupting file system on power failure.
>> You should test it heavily.
>>
>
> Thanks for that.
>
> But we are not using OCZ (also know they are not reliable).
>
> The SSD in this server is INTEL SSDSC2CW240A3.
>
> I can't try the latest redhat kernel on this system, because after
> converting it to deb it seems to be not working.
>
> But I believe fix should be in 2.6.32-358.18.1.el6.centos.plus.x86_64.
>
>>
>> On Aug 29, 2013, at 03:52 , Kir Kolyshkin  wrote:
>>
>>  On 08/28/2013 06:34 AM, spameden wrote:
>>
>>
>>
>>
>> 2013/8/28 Kir Kolyshkin 
>>
>>>  On 08/27/2013 08:20 AM, spameden wrote:
>>>
>>>  ArchLinux wiki says:
>>> *Warning: *Users need to be certain that kernel version 2.6.33 or above
>>> is being used AND that their SSD supports TRIM before attempting to mount a
>>> partition with the discard flag. Data loss can occur otherwise!
>>>
>>>  So I guess it's not in the OpenVZ kernel?
>>>
>>> I'd like to use TRIM because it increases performance to SSD drastically!
>>>
>>>
>>>  You'd better check it with Red Hat, looking into their RHEL6
>>> documentation.
>>>
>>> My quick googling for "rhel6 kernel ssd discard" shows that rhel6 kernel
>>> do support trim, they have backported it (as well as tons of other stuff,
>>> so this is hardly 2.6.32 kernel anymore).
>>>
>>
>>  I've just tested via hdparm (ofc it's not a perfect tool to test out
>> disk performance but still), here is what I get on the latest
>> 2.6.32-042stab079.5:
>>
>> # hdparm -t /dev/mapper/vg-root
>> /dev/mapper/vg-root:
>>  Timing buffered disk reads: 828 MB in  3.00 seconds = 275.56 MB/sec
>>
>>  on standard debian-7 kernel (3.2.0-4-amd64):
>> # hdparm -t /dev/mapper/vg-root
>> /dev/mapper/vg-root:
>>  Timing buffered disk reads: 1144 MB in  3.00 seconds = 381.15 MB/sec
>>
>>  and it's only read speed test.
>>
>>  I don't get why it differs so much?
>>
>>
>> My suggestion is, since this functionality is not directly related to
>> OpenVZ, and
>> we usually don't change anything in this code (unless there is a reason
>> to), to
>> try reproducing it on a stock RHEL6 kernel and, if it is reproducible,
>> file a bug
>> to red hat or, if it's not reproducible, file a bug to openvz.
>>
>> Kir.
>>  ___
>> 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
>>
>>
> ___
> 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
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

2013/8/29 Kirill Korotaev 

> I also want to add that SSD models referred to in  the bug (like OCZ one)
> are not server grade and you guys risk very much loosing your data or
> corrupting file system on power failure.
> You should test it heavily.
>

Thanks for that.

But we are not using OCZ (also know they are not reliable).

The SSD in this server is INTEL SSDSC2CW240A3.

I can't try the latest redhat kernel on this system, because after
converting it to deb it seems to be not working.

But I believe fix should be in 2.6.32-358.18.1.el6.centos.plus.x86_64.

>
> On Aug 29, 2013, at 03:52 , Kir Kolyshkin  wrote:
>
>  On 08/28/2013 06:34 AM, spameden wrote:
>
>
>
>
> 2013/8/28 Kir Kolyshkin 
>
>>  On 08/27/2013 08:20 AM, spameden wrote:
>>
>>  ArchLinux wiki says:
>> *Warning: *Users need to be certain that kernel version 2.6.33 or above
>> is being used AND that their SSD supports TRIM before attempting to mount a
>> partition with the discard flag. Data loss can occur otherwise!
>>
>>  So I guess it's not in the OpenVZ kernel?
>>
>> I'd like to use TRIM because it increases performance to SSD drastically!
>>
>>
>>  You'd better check it with Red Hat, looking into their RHEL6
>> documentation.
>>
>> My quick googling for "rhel6 kernel ssd discard" shows that rhel6 kernel
>> do support trim, they have backported it (as well as tons of other stuff,
>> so this is hardly 2.6.32 kernel anymore).
>>
>
>  I've just tested via hdparm (ofc it's not a perfect tool to test out
> disk performance but still), here is what I get on the latest
> 2.6.32-042stab079.5:
>
> # hdparm -t /dev/mapper/vg-root
> /dev/mapper/vg-root:
>  Timing buffered disk reads: 828 MB in  3.00 seconds = 275.56 MB/sec
>
>  on standard debian-7 kernel (3.2.0-4-amd64):
> # hdparm -t /dev/mapper/vg-root
> /dev/mapper/vg-root:
>  Timing buffered disk reads: 1144 MB in  3.00 seconds = 381.15 MB/sec
>
>  and it's only read speed test.
>
>  I don't get why it differs so much?
>
>
> My suggestion is, since this functionality is not directly related to
> OpenVZ, and
> we usually don't change anything in this code (unless there is a reason
> to), to
> try reproducing it on a stock RHEL6 kernel and, if it is reproducible,
> file a bug
> to red hat or, if it's not reproducible, file a bug to openvz.
>
> Kir.
>  ___
> 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
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

I guess I hit this bug:

http://bugs.centos.org/view.php?id=6548

so hopefully it will be fixed sometime soon and include in OpenVZ

can't really migrate to XEN right now yet due lack of knowledge and very
used to OpenVZ.


2013/8/28 spameden 

>
>
>
> 2013/8/28 Kir Kolyshkin 
>
>>  On 08/27/2013 08:20 AM, spameden wrote:
>>
>>  ArchLinux wiki says:
>> *Warning: *Users need to be certain that kernel version 2.6.33 or above
>> is being used AND that their SSD supports TRIM before attempting to mount a
>> partition with the discard flag. Data loss can occur otherwise!
>>
>>  So I guess it's not in the OpenVZ kernel?
>>
>> I'd like to use TRIM because it increases performance to SSD drastically!
>>
>>
>> You'd better check it with Red Hat, looking into their RHEL6
>> documentation.
>>
>> My quick googling for "rhel6 kernel ssd discard" shows that rhel6 kernel
>> do support trim, they have backported it (as well as tons of other stuff,
>> so this is hardly 2.6.32 kernel anymore).
>>
>
> I've just tested via hdparm (ofc it's not a perfect tool to test out disk
> performance but still), here is what I get on the latest
> 2.6.32-042stab079.5:
>
> # hdparm -t /dev/mapper/vg-root
> /dev/mapper/vg-root:
>  Timing buffered disk reads: 828 MB in  3.00 seconds = 275.56 MB/sec
>
> on standard debian-7 kernel (3.2.0-4-amd64):
> # hdparm -t /dev/mapper/vg-root
> /dev/mapper/vg-root:
>  Timing buffered disk reads: 1144 MB in  3.00 seconds = 381.15 MB/sec
>
> and it's only read speed test.
>
> I don't get why it differs so much?
>
>
>
>>
>>
>>
>>
>> 2013/8/27 spameden 
>>
>>>  is it implemented?
>>>
>>>  I've tried on 3.2.0-4 debian wheezy default kernel it's working just
>>> fine:
>>> # dmsetup table
>>> vg0-home: 0 443277312 linear 9:1 25166208
>>> home: 0 443273216 crypt aes-cbc-plain
>>>  0 253:2
>>> 4096 1 allow_discards
>>>
>>> But not on OpenVZ's 2.6.32.:
>>> # dmsetup table
>>> vg0-home: 0 443277312 linear 9:1 25166208
>>> home: 0 443273216 crypt aes-cbc-plain
>>>  0 253:2
>>> 4096
>>> vg0-swap: 0 4194304 linear 9:1 20971904
>>> vg0-root: 0 20971520 linear 9:1 384
>>>
>>>
>>>
>>>
>>
>>
>> ___
>> Users mailing listus...@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>>
>> ___
>> 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

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

2013/8/28 Kir Kolyshkin 

>  On 08/27/2013 08:20 AM, spameden wrote:
>
>  ArchLinux wiki says:
> *Warning: *Users need to be certain that kernel version 2.6.33 or above
> is being used AND that their SSD supports TRIM before attempting to mount a
> partition with the discard flag. Data loss can occur otherwise!
>
>  So I guess it's not in the OpenVZ kernel?
>
> I'd like to use TRIM because it increases performance to SSD drastically!
>
>
> You'd better check it with Red Hat, looking into their RHEL6 documentation.
>
> My quick googling for "rhel6 kernel ssd discard" shows that rhel6 kernel
> do support trim, they have backported it (as well as tons of other stuff,
> so this is hardly 2.6.32 kernel anymore).
>

I've just tested via hdparm (ofc it's not a perfect tool to test out disk
performance but still), here is what I get on the latest
2.6.32-042stab079.5:

# hdparm -t /dev/mapper/vg-root
/dev/mapper/vg-root:
 Timing buffered disk reads: 828 MB in  3.00 seconds = 275.56 MB/sec

on standard debian-7 kernel (3.2.0-4-amd64):
# hdparm -t /dev/mapper/vg-root
/dev/mapper/vg-root:
 Timing buffered disk reads: 1144 MB in  3.00 seconds = 381.15 MB/sec

and it's only read speed test.

I don't get why it differs so much?



>
>
>
>
> 2013/8/27 spameden 
>
>>  is it implemented?
>>
>>  I've tried on 3.2.0-4 debian wheezy default kernel it's working just
>> fine:
>> # dmsetup table
>> vg0-home: 0 443277312 linear 9:1 25166208
>> home: 0 443273216 crypt aes-cbc-plain
>>  0 253:2
>> 4096 1 allow_discards
>>
>> But not on OpenVZ's 2.6.32.:
>> # dmsetup table
>> vg0-home: 0 443277312 linear 9:1 25166208
>> home: 0 443273216 crypt aes-cbc-plain
>>  0 253:2
>> 4096
>> vg0-swap: 0 4194304 linear 9:1 20971904
>> vg0-root: 0 20971520 linear 9:1 384
>>
>>
>>
>>
>
>
> ___
> Users mailing listus...@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
>
>
> ___
> 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

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

Hi.


2013/8/27 David Brown 

> The answer is quite simple - don't use "discard" mounts.  They make your
> SSD much slower, especially for metadata-heavy operations.
>

I tend to disagree with this.

On the writing operations I saw at least 2x speed with discard / TRIM
enabled on dm-crypt LUKS partition.

On the another note it's not secure to use TRIM on dm-crypt, because
attacker might identify which blocks are free and potentially can detect
filesystem.

The fix for dm-crypt devices only will be in 3.1.x mainline, so don't think
it's gonna be ported in the current 2.6.32 branch.




> The problem is that the halfwits that added TRIM to the SATA
> specifications made it a synchronous operation, so it blocks all queues
> and buffers.  They also failed to give it proper semantics, such as
> specifying that reading from a TRIM'ed sector would give all zeros.  If
> the people behind this nonsense had read the SCSI specifications for the
> equivalent operation, they would have made a much better TRIM that was
> asynchronous, could be queued, and would guarantee reading all zeros
> from a TRIM'ed block - which would have been much more useful.
>

Well, if you won't use TRIM, you'll see in the future write performance
degraded all because of the SSD internals.


> Off-line TRIM using fstrim is useful, but not essential if you have
> bought a half-decent SSD that is not too small, and not too old.  So use
> fstrim if it works on your setup - but don't worry if it doesn't.  It's
> very unlikely that you will notice the difference.
>

I read about it, but don't think it's a proper solution, I'm thinking about
trying another virtualization technology instead.

LXC seems to be unstable for production yet.

Thinking about trying XEN on the more recent kernel.


>
> Hope that helps,
>
> David
>
>
>
> On 27/08/13 17:10, spameden wrote:
> > is it implemented?
> >
> > I've tried on 3.2.0-4 debian wheezy default kernel it's working just
> fine:
> > # dmsetup table
> > vg0-home: 0 443277312 linear 9:1 25166208
> > home: 0 443273216 crypt aes-cbc-plain
> >  0 253:2
> > 4096 1 allow_discards
> >
> > But not on OpenVZ's 2.6.32.:
> > # dmsetup table
> > vg0-home: 0 443277312 linear 9:1 25166208
> > home: 0 443273216 crypt aes-cbc-plain
> >  0 253:2
> > 4096
> > vg0-swap: 0 4194304 linear 9:1 20971904
> > vg0-root: 0 20971520 linear 9:1 384
> >
> >
> >
> >
> >
> > ___
> > 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

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

Please forgive me once again, I've found the problem.

My initial request was about discard on dm-crypt (encrypted LUKS device).

>From the link you sent it seems to be not supported:

"The only DM targets that do not support discards are dm-snapshot,
dm-crypt, and dm-raid45. Discard support for the dm-mirror was added in Red
Hat Enterprise Linux 6.1. "

Very sad, any chance of adding this support?


2013/8/27 LightDot 

> What's Arch got to do with OpenVZ RHEL based kernel?
>
> Red Hat backports different functionality into RHEL kernel and the thing
> you're using is far far from plain vanilla 2.6.32 or any other distro's
> 2.6.32.
>
> Anyway, RHEL 6 does have trim support, simply refer to the relevant docs:
>
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/newmds-ssdtuning.html
>
> There's also a myriad of how-to's on the net about RHEL and SSDs... There
> are also Proxmox threads about SSDs and Debian converted OpenVZ RHEL
> kernels, if that's what you're using.
>
> Regards
>
>
>
>
> On Tue, Aug 27, 2013 at 5:20 PM, spameden  wrote:
>
>> ArchLinux wiki says:
>> *Warning: *Users need to be certain that kernel version 2.6.33 or above
>> is being used AND that their SSD supports TRIM before attempting to mount a
>> partition with the discard flag. Data loss can occur otherwise!
>>
>> So I guess it's not in the OpenVZ kernel?
>>
>> I'd like to use TRIM because it increases performance to SSD drastically!
>>
>>
>> 2013/8/27 spameden 
>>
>>> is it implemented?
>>>
>>> I've tried on 3.2.0-4 debian wheezy default kernel it's working just
>>> fine:
>>> # dmsetup table
>>> vg0-home: 0 443277312 linear 9:1 25166208
>>> home: 0 443273216 crypt aes-cbc-plain
>>>  0 253:2
>>> 4096 1 allow_discards
>>>
>>> But not on OpenVZ's 2.6.32.:
>>> # dmsetup table
>>> vg0-home: 0 443277312 linear 9:1 25166208
>>> home: 0 443273216 crypt aes-cbc-plain
>>>  0 253:2
>>> 4096
>>> vg0-swap: 0 4194304 linear 9:1 20971904
>>> vg0-root: 0 20971520 linear 9:1 384
>>>
>>>
>>>
>>>
>>
>> ___
>> 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
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

2013/8/27 LightDot 

> What's Arch got to do with OpenVZ RHEL based kernel?
>

I'm sorry If I quoted wrong, I just found this info occasionally.
And as I stated below it's not working on OpenVZ kernel for me.


> Red Hat backports different functionality into RHEL kernel and the thing
> you're using is far far from plain vanilla 2.6.32 or any other distro's
> 2.6.32.
>
> Anyway, RHEL 6 does have trim support, simply refer to the relevant docs:
>
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/newmds-ssdtuning.html
>
> There's also a myriad of how-to's on the net about RHEL and SSDs... There
> are also Proxmox threads about SSDs and Debian converted OpenVZ RHEL
> kernels, if that's what you're using.
>

Thanks. I'll check this out!

>
> Regards
>
>
>
>
> On Tue, Aug 27, 2013 at 5:20 PM, spameden  wrote:
>
>> ArchLinux wiki says:
>> *Warning: *Users need to be certain that kernel version 2.6.33 or above
>> is being used AND that their SSD supports TRIM before attempting to mount a
>> partition with the discard flag. Data loss can occur otherwise!
>>
>> So I guess it's not in the OpenVZ kernel?
>>
>> I'd like to use TRIM because it increases performance to SSD drastically!
>>
>>
>> 2013/8/27 spameden 
>>
>>> is it implemented?
>>>
>>> I've tried on 3.2.0-4 debian wheezy default kernel it's working just
>>> fine:
>>> # dmsetup table
>>> vg0-home: 0 443277312 linear 9:1 25166208
>>> home: 0 443273216 crypt aes-cbc-plain
>>>  0 253:2
>>> 4096 1 allow_discards
>>>
>>> But not on OpenVZ's 2.6.32.:
>>> # dmsetup table
>>> vg0-home: 0 443277312 linear 9:1 25166208
>>> home: 0 443273216 crypt aes-cbc-plain
>>>  0 253:2
>>> 4096
>>> vg0-swap: 0 4194304 linear 9:1 20971904
>>> vg0-root: 0 20971520 linear 9:1 384
>>>
>>>
>>>
>>>
>>
>> ___
>> 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
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] discard support for SSD in OpenVZ kernel

[spameden]

ArchLinux wiki says:
*Warning: *Users need to be certain that kernel version 2.6.33 or above is
being used AND that their SSD supports TRIM before attempting to mount a
partition with the discard flag. Data loss can occur otherwise!

So I guess it's not in the OpenVZ kernel?

I'd like to use TRIM because it increases performance to SSD drastically!


2013/8/27 spameden 

> is it implemented?
>
> I've tried on 3.2.0-4 debian wheezy default kernel it's working just fine:
> # dmsetup table
> vg0-home: 0 443277312 linear 9:1 25166208
> home: 0 443273216 crypt aes-cbc-plain
>  0 253:2
> 4096 1 allow_discards
>
> But not on OpenVZ's 2.6.32.:
> # dmsetup table
> vg0-home: 0 443277312 linear 9:1 25166208
> home: 0 443273216 crypt aes-cbc-plain
>  0 253:2
> 4096
> vg0-swap: 0 4194304 linear 9:1 20971904
> vg0-root: 0 20971520 linear 9:1 384
>
>
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

[Users] discard support for SSD in OpenVZ kernel

[spameden]

is it implemented?

I've tried on 3.2.0-4 debian wheezy default kernel it's working just fine:
# dmsetup table
vg0-home: 0 443277312 linear 9:1 25166208
home: 0 443273216 crypt aes-cbc-plain
 0 253:2
4096 1 allow_discards

But not on OpenVZ's 2.6.32.:
# dmsetup table
vg0-home: 0 443277312 linear 9:1 25166208
home: 0 443273216 crypt aes-cbc-plain
 0 253:2
4096
vg0-swap: 0 4194304 linear 9:1 20971904
vg0-root: 0 20971520 linear 9:1 384
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Fwd: vzctl 4.5 vzlist disappeared?

[spameden]

There is an error however when installing vzctl:

Setting up vzctl (4.5-1) ...
/var/lib/dpkg/info/vzctl.postinst: line 42: test: configure: integer
expression expected

Line 42:

41 # Run post-install script only when installing
42 test $1 -eq 1 && /usr/libexec/vzctl/scripts/vz-postinstall

But it works now, libcgroup1 was installed before and I didnt move lib64 to
lib, it's already a symlink I think.


2013/8/25 spameden 

>
>
>
> 2013/8/25 Kir Kolyshkin 
>
>>  On 08/25/2013 12:46 AM, spameden wrote:
>>
>>  # dpkg -L vzctl|grep vzlist
>> # dpkg -L vzctl-core|grep vzlist
>> #
>>
>>  nothing, i converted rpm to deb, could it be the issue?
>>
>>
>> I can't reproduce it either. You must did something wrong, and since you
>> don't provide
>> detailed logs of what you did, I can't tell what exactly.
>>
>> This is what I did, trying to reproduce your problem:
>>
>> root@kir-deb71-ovz:~# sha1sum *rpm
>> d84d6ad6910263ac6bd366292d1c95d458567afe  vzctl-4.5-1.x86_64.rpm
>> 0f8069b1a4d3e6c7e97867cda7842cca8c750286  vzctl-core-4.5-1.x86_64.rpm
>>
>> root@kir-deb71-ovz:~# ls -l *.rpm
>> -rw-r--r-- 1 root root 124630 Aug 25 01:18 vzctl-4.5-1.x86_64.rpm
>> -rw-r--r-- 1 root root 274686 Aug 25 01:18 vzctl-core-4.5-1.x86_64.rpm
>>
>>
>> fakeroot alien --to-deb --scripts --keep-version vz*.rpm
>> warning: vzctl-4.5-1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID
>> a7a1d4b6: NOKEY
>> 
>> vzctl_4.5-1_amd64.deb generated
>> warning: vzctl-core-4.5-1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key
>> ID a7a1d4b6: NOKEY
>> 
>> vzctl-core_4.5-1_amd64.deb generated
>>
>> root@kir-deb71-ovz:~# ls -l vz*_4.5-1_amd64.deb
>> -rw-r--r-- 1 root root 243128 Aug 25 01:23 vzctl-core_4.5-1_amd64.deb
>> -rw-r--r-- 1 root root  98334 Aug 25 01:23 vzctl_4.5-1_amd64.deb
>>
>> # dpkg -i vzctl_4.5-1_amd64.deb vzctl-core_4.5-1_amd64.deb
>> 
>>
>>
>> # dpkg -L vzctl | grep vzlist
>> /usr/share/man/man8/vzlist.8.gz
>> /usr/sbin/vzlist
>>
>>
>> Note however vzlist doesn't work thought, I had to do this:
>>
>> mv /usr/lib64/* /usr/lib
>> ldconfig
>> apt-get install libcgroup1
>>
>> After that it works just fine:
>>
>> root@kir-deb71-ovz:~# vzlist -a
>>
>>   CTID  NPROC STATUSIP_ADDR HOSTNAME
>>101 20 running   -   -
>>102  - stopped   -   -
>>
>>
>>
>>
>>
>>  2013/8/25 Kir Kolyshkin 
>>
>>>  On 08/24/2013 08:09 AM, spameden wrote:
>>>
>>>   It seems there is no vzlist anymore in 4.5 version of vzctl.
>>>
>>>
>>>  You must be kidding.
>>>
>>> # vzlist -a
>>>   CTID  NPROC STATUSIP_ADDR HOSTNAME
>>> <>
>>>
>>> # rpm -qf /usr/sbin/vzlist
>>> vzctl-4.5-1.x86_64
>>>
>>> # vzctl --version
>>> vzctl version 4.5
>>>
>>> # rpm -q vzctl-core vzctl
>>> vzctl-core-4.5-1.x86_64
>>> vzctl-4.5-1.x86_64
>>>
>>>
>>> why it was removed?
>>>
>>>
>>> It was not.
>>>
>>> ___
>>> Users mailing list
>>> Users@openvz.org
>>> https://lists.openvz.org/mailman/listinfo/users
>>>
>>>
>>
>>
>> ___
>> Users mailing 
>> listUsers@openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>>
>>
>>
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
> that's weird, I have same sha1sums on rpm
>
> I've just did fakeroot again and vzlist is here .. pretty odd, but solved
> now.
>
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Fwd: vzctl 4.5 vzlist disappeared?

[spameden]

2013/8/25 Kir Kolyshkin 

>  On 08/25/2013 12:46 AM, spameden wrote:
>
>  # dpkg -L vzctl|grep vzlist
> # dpkg -L vzctl-core|grep vzlist
> #
>
>  nothing, i converted rpm to deb, could it be the issue?
>
>
> I can't reproduce it either. You must did something wrong, and since you
> don't provide
> detailed logs of what you did, I can't tell what exactly.
>
> This is what I did, trying to reproduce your problem:
>
> root@kir-deb71-ovz:~# sha1sum *rpm
> d84d6ad6910263ac6bd366292d1c95d458567afe  vzctl-4.5-1.x86_64.rpm
> 0f8069b1a4d3e6c7e97867cda7842cca8c750286  vzctl-core-4.5-1.x86_64.rpm
>
> root@kir-deb71-ovz:~# ls -l *.rpm
> -rw-r--r-- 1 root root 124630 Aug 25 01:18 vzctl-4.5-1.x86_64.rpm
> -rw-r--r-- 1 root root 274686 Aug 25 01:18 vzctl-core-4.5-1.x86_64.rpm
>
>
> fakeroot alien --to-deb --scripts --keep-version vz*.rpm
> warning: vzctl-4.5-1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID
> a7a1d4b6: NOKEY
> 
> vzctl_4.5-1_amd64.deb generated
> warning: vzctl-core-4.5-1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID
> a7a1d4b6: NOKEY
> 
> vzctl-core_4.5-1_amd64.deb generated
>
> root@kir-deb71-ovz:~# ls -l vz*_4.5-1_amd64.deb
> -rw-r--r-- 1 root root 243128 Aug 25 01:23 vzctl-core_4.5-1_amd64.deb
> -rw-r--r-- 1 root root  98334 Aug 25 01:23 vzctl_4.5-1_amd64.deb
>
> # dpkg -i vzctl_4.5-1_amd64.deb vzctl-core_4.5-1_amd64.deb
> 
>
>
> # dpkg -L vzctl | grep vzlist
> /usr/share/man/man8/vzlist.8.gz
> /usr/sbin/vzlist
>
>
> Note however vzlist doesn't work thought, I had to do this:
>
> mv /usr/lib64/* /usr/lib
> ldconfig
> apt-get install libcgroup1
>
> After that it works just fine:
>
> root@kir-deb71-ovz:~# vzlist -a
>
>   CTID  NPROC STATUSIP_ADDR HOSTNAME
>101 20 running   -   -
>102  - stopped   -   -
>
>
>
>
>
>  2013/8/25 Kir Kolyshkin 
>
>>  On 08/24/2013 08:09 AM, spameden wrote:
>>
>>   It seems there is no vzlist anymore in 4.5 version of vzctl.
>>
>>
>>  You must be kidding.
>>
>> # vzlist -a
>>   CTID  NPROC STATUSIP_ADDR HOSTNAME
>> <>
>>
>> # rpm -qf /usr/sbin/vzlist
>> vzctl-4.5-1.x86_64
>>
>> # vzctl --version
>> vzctl version 4.5
>>
>> # rpm -q vzctl-core vzctl
>> vzctl-core-4.5-1.x86_64
>> vzctl-4.5-1.x86_64
>>
>>
>> why it was removed?
>>
>>
>> It was not.
>>
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>
>
> ___
> Users mailing 
> listUsers@openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
>
that's weird, I have same sha1sums on rpm

I've just did fakeroot again and vzlist is here .. pretty odd, but solved
now.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Fwd: vzctl 4.5 vzlist disappeared?

[spameden]

2013/8/25 spameden 

> # dpkg -L vzctl|grep vzlist
> # dpkg -L vzctl-core|grep vzlist
> #
>
> nothing, i converted rpm to deb, could it be the issue?
>
>
> 2013/8/25 Kir Kolyshkin 
>
>>  On 08/24/2013 08:09 AM, spameden wrote:
>>
>>   It seems there is no vzlist anymore in 4.5 version of vzctl.
>>
>>
>> You must be kidding.
>>
>> # vzlist -a
>>   CTID  NPROC STATUSIP_ADDR HOSTNAME
>> <>
>>
>> # rpm -qf /usr/sbin/vzlist
>> vzctl-4.5-1.x86_64
>>
>> # vzctl --version
>> vzctl version 4.5
>>
>> # rpm -q vzctl-core vzctl
>> vzctl-core-4.5-1.x86_64
>> vzctl-4.5-1.x86_64
>>
>>
>> why it was removed?
>>
>>
>> It was not.
>>
>> ___
>> Users mailing list
>> Users@openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>
this is how I've converted:

fakeroot alien --to-deb --scripts --keep-version vz*.rpm
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Fwd: vzctl 4.5 vzlist disappeared?

[spameden]

# dpkg -L vzctl|grep vzlist
# dpkg -L vzctl-core|grep vzlist
#

nothing, i converted rpm to deb, could it be the issue?


2013/8/25 Kir Kolyshkin 

>  On 08/24/2013 08:09 AM, spameden wrote:
>
>   It seems there is no vzlist anymore in 4.5 version of vzctl.
>
>
> You must be kidding.
>
> # vzlist -a
>   CTID  NPROC STATUSIP_ADDR HOSTNAME
> <>
>
> # rpm -qf /usr/sbin/vzlist
> vzctl-4.5-1.x86_64
>
> # vzctl --version
> vzctl version 4.5
>
> # rpm -q vzctl-core vzctl
> vzctl-core-4.5-1.x86_64
> vzctl-4.5-1.x86_64
>
>
> why it was removed?
>
>
> It was not.
>
> ___
> 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

[Users] Fwd: vzctl 4.5 vzlist disappeared?

[spameden]

It seems there is no vzlist anymore in 4.5 version of vzctl.

why it was removed?

thanks
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] [Debian] VE network isolation

[spameden]

2013/8/20 Ola Lundqvist 

> Could be so. I do not know the answer. users@openvz.org
> or the forum may know.
>

users@openvz.org is already copied here.


>
> However if you have two interfaces I actually think your
> messages go through the venet interface. I may be wrong
> however.
>

I've tested through lo device in VE without any additional veth devices or
venet IP addresses.

But I guess lo is going through venet0 as well in VE?


>
> I mean to 202 192.168.203.* is in another network and
> would be routed to the venet if. And the other way around.
> As you have ip_forwarding enabled it would then route it
> to the other network.
>
> Network isolation on the same machine can be tricky.
>
> In any case, you may find better answers on the forum.
>
> Also you probabably need to use wireshark or tcpdump to
> find out what actually happens. :-)
>

Thanks for the tip.

Actually its bit weird what I'm getting through lo device:

# ip r
default dev lo  scope link

# ping 1.2.3.4
PING 1.2.3.4 (1.2.3.4) 56(84) bytes of data.
64 bytes from 1.2.3.4: icmp_req=1 ttl=64 time=0.036 ms
64 bytes from 1.2.3.4: icmp_req=2 ttl=64 time=0.027 ms
^C
--- 1.2.3.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.027/0.031/0.036/0.007 ms

# ping 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 56(84) bytes of data.
64 bytes from 3.3.3.3: icmp_req=1 ttl=64 time=0.037 ms
^C
--- 3.3.3.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.037/0.037/0.037/0.000 ms

It means if I ping _ANY_ IP through lo device it gives me answer back? why?


>
> // Ola
>
> On Tue, Aug 20, 2013 at 01:23:29AM +0400, spameden wrote:
> >The problem here is actually much wider..
> >I can access any of the venet0 assigned IP address from the container
> >via lo interface.
> >E.g. if I have another container with an IP address of 1.2.3.4 I can
> >access it through lo interface from this container.
> >
> >2013/8/20 spameden <[1]spame...@gmail.com>
> >
> >2013/8/20 Ola Lundqvist <[2]o...@inguza.com>
> >
> >  Hi
> >  It all depends on how you have done things. There are a few things
> >  that is not fully clear that you should probably add in a forum
> >  question.
> >  You mention that you use both venet and veth devices. It
> >  is not clear what you use in this situation.
> >  (To my knowledge only veth makes sense to use with vzbr).
> >
> >Yes, I'm using both devices.
> >I've added veth device to the vzbr201 device with private IP address,
> >e.g. 192.168.201.2.
> >venet0 is used for public internet address, e.g. 1.2.3.4
> >
> >  It is also not clear how you add veth to the bridge.
> >
> >I'm adding it via /etc/vz/vznet.conf:
> >#!/bin/bash
> >EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"
> >
> >  I guess you have read this article:
> >  [3]http://openvz.org/Virtual_Ethernet_device
> >
> >Did already.
> >
> >  Also it may be so that even though you have added them to
> >  different bridges, then the bridges may be connected to something
> >  common. It is not clear from the text below.
> >
> >How bridges can be connected to the same thing if they are different?
> >
> >  Hope this helps for your forum question.
> >  Cheers,
> >  // Ola
> >
> >On Tue, Aug 20, 2013 at 12:53:23AM +0400, spameden wrote:
> >>Yes, I have forwarding turned on.
> >># sysctl -a 2>/dev/null|grep ip_forward
> >>net.ipv4.ip_forward = 1
> >>Surely, I can try to ban this via iptables, but it's so much
> >hassle to
> >>ban each time.
> >>I thought it should "work out out of the box"..
> >>Anyways, thanks for your point, I will try to post this on
> forums.
> >>
> >
> >  >2013/8/20 Ola Lundqvist <[1][4]o...@debian.org>
> >
> >>
> >>  Hi
> >>  This kind of question belong more on the openvz forum
> >
> >  >  [2][5]http://forum.openvz.org/.
> >
> >>  Please ask there.
> >>  However I think it is not worwarded through "lo", instead I
> >guess
> >>  you
> >>  have IP forwarding turned on in the kernel and as the kernel
> >gets
> >>  aware
> >>  of those datagrams it will forward it to the cor

Re: [Users] "Permission denied" when trying to help a stuck destroy

[spameden]

Obviously your system is compromised.


I suggest reinstalling whole container / check host system as well and
other servers if you had same passwords in use.


2013/8/20 Kevin Holly 

> On 06/11/2013 08:00 PM, Kir Kolyshkin wrote:
> > On 06/11/2013 02:33 AM, Kevin Holly wrote:
> >> Hello,
> >>
> >> i already had this problem but forgot how to fix it:
> >>
> >> vztmp-Directory contains parts of a 3 month old container, which was
> >> destroyed. When i try to "find -delete" the directory, i get:
> >>
> >> [root@bedrock vzctl-rm-me.guj6L7]# find -delete
> >> find: cannot delete `./usr/lib/libsh/shsb': Permission denied
> >> find: cannot delete `./usr/lib/libsh/utilz': Permission denied
> >> find: cannot delete `./usr/lib/libsh/.owned': Permission denied
> >> find: cannot delete `./usr/lib/libsh/.sniff': Permission denied
> >> find: cannot delete `./usr/lib/libsh/.backup': Permission denied
> >> find: cannot delete `./usr/lib/libsh/.bashrc': Permission denied
> >> find: cannot delete `./usr/lib/libsh/hide': Permission denied
> >> find: cannot delete `./usr/lib/libsh': Operation not permitted
> >> find: cannot delete `./usr/lib': Directory not empty
> >> find: cannot delete `./usr': Directory not empty
> >> find: cannot delete `./lib/libsh.so/shhk': Permission denied
> >> find: cannot delete `./lib/libsh.so/shhk.pub': Permission denied
> >> find: cannot delete `./lib/libsh.so/bash': Permission denied
> >> find: cannot delete `./lib/libsh.so/shrs': Permission denied
> >> find: cannot delete `./lib/libsh.so/shdcf': Permission denied
> >> find: cannot delete `./lib/libsh.so': Operation not permitted
> >> find: cannot delete `./lib': Directory not empty
> >> find: cannot delete `./sbin/ttymon': Operation not permitted
> >> find: cannot delete `./sbin/ttyload': Operation not permitted
> >> find: cannot delete `./sbin/ifconfig': Operation not permitted
> >> find: cannot delete `./sbin': Directory not empty
> >> find: cannot delete `./etc/sh.conf': Operation not permitted
> >> find: cannot delete `./etc': Directory not empty
> >>
> >> lsattr shows this:
> >>
> >> [root@bedrock vzctl-rm-me.guj6L7]# lsattr etc/sh.conf
> >> s---ia---e- etc/sh.conf
> >>
> >> Anyone knows how to fix this/set the right (ch)attr?
> >
> > Something like "chattr -R -i" should work. I should probably add it to
> > vzctl destroy.
> Is it already in one of the stable releases or planned or do you still
> consider if it's a good idea to put it there?
> >
> > ___
> > Users mailing list
> > Users@openvz.org
> > https://lists.openvz.org/mailman/listinfo/users
>
> --
> Best regards
>
> Kevin Holly - r...@hallowe.lt - http://hallowe.lt/
> ___
> 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

Re: [Users] [Debian] VE network isolation

[spameden]

The problem here is actually much wider..

I can access any of the venet0 assigned IP address from the container via
lo interface.

E.g. if I have another container with an IP address of 1.2.3.4 I can access
it through lo interface from this container.


2013/8/20 spameden 

>
>
>
> 2013/8/20 Ola Lundqvist 
>
>> Hi
>>
>> It all depends on how you have done things. There are a few things
>> that is not fully clear that you should probably add in a forum
>> question.
>>
>> You mention that you use both venet and veth devices. It
>> is not clear what you use in this situation.
>> (To my knowledge only veth makes sense to use with vzbr).
>>
>
> Yes, I'm using both devices.
>
> I've added veth device to the vzbr201 device with private IP address, e.g.
> 192.168.201.2.
>
> venet0 is used for public internet address, e.g. 1.2.3.4
>
>>
>> It is also not clear how you add veth to the bridge.
>>
>
> I'm adding it via /etc/vz/vznet.conf:
>
> #!/bin/bash
> EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"
>
>
>>
>> I guess you have read this article:
>> http://openvz.org/Virtual_Ethernet_device
>>
>
> Did already.
>
>
>>
>> Also it may be so that even though you have added them to
>> different bridges, then the bridges may be connected to something
>> common. It is not clear from the text below.
>>
>
> How bridges can be connected to the same thing if they are different?
>
>>
>> Hope this helps for your forum question.
>>
>> Cheers,
>>
>> // Ola
>>
>>
>> On Tue, Aug 20, 2013 at 12:53:23AM +0400, spameden wrote:
>> >Yes, I have forwarding turned on.
>> ># sysctl -a 2>/dev/null|grep ip_forward
>> >net.ipv4.ip_forward = 1
>> >Surely, I can try to ban this via iptables, but it's so much hassle
>> to
>> >ban each time.
>> >I thought it should "work out out of the box"..
>> >Anyways, thanks for your point, I will try to post this on forums.
>> >
>> >2013/8/20 Ola Lundqvist <[1]o...@debian.org>
>> >
>> >  Hi
>> >  This kind of question belong more on the openvz forum
>> >  [2]http://forum.openvz.org/.
>> >  Please ask there.
>> >  However I think it is not worwarded through "lo", instead I guess
>> >  you
>> >  have IP forwarding turned on in the kernel and as the kernel gets
>> >  aware
>> >  of those datagrams it will forward it to the correct place. To
>> >  prevent
>> >  that I guess you have to add some firewalling rules (see iptables).
>> >  But again, this better belong on the forum, and I may be totally
>> >  wrong.
>> >  Cheers,
>> >  // Ola
>> >
>> >On Tue, Aug 20, 2013 at 12:04:42AM +0400, spameden wrote:
>> >>Hi, list.
>> >>I'm sorry for copying 2 lists, but I really want to know what
>> I'm
>> >doing
>> >>wrong.
>> >>I'm using Debian 6 Squeeze and OpenVZ CentOS kernel (converted
>> >from rpm
>> >>to deb).
>> >>I'm using veth as well as venet devices for networking.
>> >>To isolate multiple containers from each other I'm using vzbrXXX
>> >>devices on debian like this:
>> >>auto vzbr203
>> >>iface vzbr203 inet static
>> >>address 192.168.203.1
>> >>netmask   255.255.255.0
>> >>broadcast   192.168.203.255
>> >>bridge_ports none
>> >>bridge_fd 0
>> >>bridge_maxwait 0
>> >>auto vzbr202
>> >>iface vzbr202 inet static
>> >>address 192.168.202.1
>> >>netmask   255.255.255.0
>> >>broadcast   192.168.202.255
>> >>bridge_ports none
>> >>bridge_fd 0
>> >>bridge_maxwait 0
>> >>The problem I'm facing that in VE (for example with CTID 202) I
>> >can
>> >>ping or query 192.168.203.1 which is on HN of course, but I
>> >thought it
>> >>shouldn't be reachable.
>> >>Here is route table and ifconfig on CTID 202:
>> >&

Re: [Users] [Debian] VE network isolation

[spameden]

2013/8/20 Ola Lundqvist 

> Hi
>
> It all depends on how you have done things. There are a few things
> that is not fully clear that you should probably add in a forum
> question.
>
> You mention that you use both venet and veth devices. It
> is not clear what you use in this situation.
> (To my knowledge only veth makes sense to use with vzbr).
>

Yes, I'm using both devices.

I've added veth device to the vzbr201 device with private IP address, e.g.
192.168.201.2.

venet0 is used for public internet address, e.g. 1.2.3.4

>
> It is also not clear how you add veth to the bridge.
>

I'm adding it via /etc/vz/vznet.conf:

#!/bin/bash
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"


>
> I guess you have read this article:
> http://openvz.org/Virtual_Ethernet_device
>

Did already.


>
> Also it may be so that even though you have added them to
> different bridges, then the bridges may be connected to something
> common. It is not clear from the text below.
>

How bridges can be connected to the same thing if they are different?

>
> Hope this helps for your forum question.
>
> Cheers,
>
> // Ola
>
>
> On Tue, Aug 20, 2013 at 12:53:23AM +0400, spameden wrote:
> >Yes, I have forwarding turned on.
> ># sysctl -a 2>/dev/null|grep ip_forward
> >net.ipv4.ip_forward = 1
> >Surely, I can try to ban this via iptables, but it's so much hassle to
> >ban each time.
> >I thought it should "work out out of the box"..
> >Anyways, thanks for your point, I will try to post this on forums.
> >
> >2013/8/20 Ola Lundqvist <[1]o...@debian.org>
> >
> >  Hi
> >  This kind of question belong more on the openvz forum
> >  [2]http://forum.openvz.org/.
> >  Please ask there.
> >  However I think it is not worwarded through "lo", instead I guess
> >  you
> >  have IP forwarding turned on in the kernel and as the kernel gets
> >  aware
> >  of those datagrams it will forward it to the correct place. To
> >      prevent
> >  that I guess you have to add some firewalling rules (see iptables).
> >  But again, this better belong on the forum, and I may be totally
> >  wrong.
> >  Cheers,
> >  // Ola
> >
> >On Tue, Aug 20, 2013 at 12:04:42AM +0400, spameden wrote:
> >>Hi, list.
> >>I'm sorry for copying 2 lists, but I really want to know what I'm
> >doing
> >>wrong.
> >>I'm using Debian 6 Squeeze and OpenVZ CentOS kernel (converted
> >from rpm
> >>to deb).
> >>I'm using veth as well as venet devices for networking.
> >>To isolate multiple containers from each other I'm using vzbrXXX
> >>devices on debian like this:
> >>auto vzbr203
> >>iface vzbr203 inet static
> >>address 192.168.203.1
> >>netmask   255.255.255.0
> >>broadcast   192.168.203.255
> >>bridge_ports none
> >>bridge_fd 0
> >>bridge_maxwait 0
> >>auto vzbr202
> >>iface vzbr202 inet static
> >>address 192.168.202.1
> >>netmask   255.255.255.0
> >>broadcast   192.168.202.255
> >>bridge_ports none
> >>bridge_fd 0
> >>bridge_maxwait 0
> >>The problem I'm facing that in VE (for example with CTID 202) I
> >can
> >>ping or query 192.168.203.1 which is on HN of course, but I
> >thought it
> >>shouldn't be reachable.
> >>Here is route table and ifconfig on CTID 202:
> >># ip r
> >>default dev lo  scope link
> >># ifconfig -a
> >>loLink encap:Local Loopback
> >>  inet addr:127.0.0.1  Mask:255.0.0.0
> >>  inet6 addr: ::1/128 Scope:Host
> >>  UP LOOPBACK RUNNING  MTU:16436  Metric:1
> >>  RX packets:84021 errors:0 dropped:0 overruns:0 frame:0
> >>  TX packets:84021 errors:0 dropped:0 overruns:0
> carrier:0
> >>  collisions:0 txqueuelen:0
> >>  RX bytes:5045068 (4.8 MiB)  TX bytes:5045068 (4.8 MiB)
> >>venet0Link encap:UNSPEC  HWaddr
> >   

Re: [Users] [Debian] VE network isolation

[spameden]

Yes, I have forwarding turned on.

# sysctl -a 2>/dev/null|grep ip_forward
net.ipv4.ip_forward = 1

Surely, I can try to ban this via iptables, but it's so much hassle to ban
each time.

I thought it should "work out out of the box"..

Anyways, thanks for your point, I will try to post this on forums.




2013/8/20 Ola Lundqvist 

> Hi
>
> This kind of question belong more on the openvz forum
> http://forum.openvz.org/.
>
> Please ask there.
>
> However I think it is not worwarded through "lo", instead I guess you
> have IP forwarding turned on in the kernel and as the kernel gets aware
> of those datagrams it will forward it to the correct place. To prevent
> that I guess you have to add some firewalling rules (see iptables).
>
> But again, this better belong on the forum, and I may be totally wrong.
>
> Cheers,
>
> // Ola
>
> On Tue, Aug 20, 2013 at 12:04:42AM +0400, spameden wrote:
> >Hi, list.
> >I'm sorry for copying 2 lists, but I really want to know what I'm
> doing
> >wrong.
> >I'm using Debian 6 Squeeze and OpenVZ CentOS kernel (converted from
> rpm
> >to deb).
> >I'm using veth as well as venet devices for networking.
> >To isolate multiple containers from each other I'm using vzbrXXX
> >devices on debian like this:
> >auto vzbr203
> >iface vzbr203 inet static
> >address 192.168.203.1
> >netmask   255.255.255.0
> >broadcast   192.168.203.255
> >bridge_ports none
> >bridge_fd 0
> >bridge_maxwait 0
> >auto vzbr202
> >iface vzbr202 inet static
> >address 192.168.202.1
> >netmask   255.255.255.0
> >broadcast   192.168.202.255
> >bridge_ports none
> >bridge_fd 0
> >bridge_maxwait 0
> >The problem I'm facing that in VE (for example with CTID 202) I can
> >ping or query 192.168.203.1 which is on HN of course, but I thought it
> >shouldn't be reachable.
> >Here is route table and ifconfig on CTID 202:
> ># ip r
> >default dev lo  scope link
> ># ifconfig -a
> >loLink encap:Local Loopback
> >  inet addr:127.0.0.1  Mask:255.0.0.0
> >  inet6 addr: ::1/128 Scope:Host
> >  UP LOOPBACK RUNNING  MTU:16436  Metric:1
> >  RX packets:84021 errors:0 dropped:0 overruns:0 frame:0
> >  TX packets:84021 errors:0 dropped:0 overruns:0 carrier:0
> >  collisions:0 txqueuelen:0
> >  RX bytes:5045068 (4.8 MiB)  TX bytes:5045068 (4.8 MiB)
> >venet0Link encap:UNSPEC  HWaddr
> >00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> >  BROADCAST POINTOPOINT NOARP  MTU:1500  Metric:1
> >  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> >  collisions:0 txqueuelen:0
> >  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> >So I guess it's going through lo device? Why and how can I block this?
> >Many thanks.
>
> > ___
> > Debian mailing list
> > deb...@openvz.org
> > https://lists.openvz.org/mailman/listinfo/debian
>
>
> --
>  - Ola Lundqvist ---
> /  o...@debian.org Annebergsslingan 37  \
> |  o...@inguza.com  654 65 KARLSTAD  |
> |  http://inguza.com/  +46 (0)70-332 1551   |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
>  ---
>
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

[Users] VE network isolation

[spameden]

Hi, list.

I'm sorry for copying 2 lists, but I really want to know what I'm doing
wrong.

I'm using Debian 6 Squeeze and OpenVZ CentOS kernel (converted from rpm to
deb).

I'm using veth as well as venet devices for networking.

To isolate multiple containers from each other I'm using vzbrXXX devices on
debian like this:

auto vzbr203
iface vzbr203 inet static
address 192.168.203.1
netmask   255.255.255.0
broadcast   192.168.203.255
bridge_ports none
bridge_fd 0
bridge_maxwait 0

auto vzbr202
iface vzbr202 inet static
address 192.168.202.1
netmask   255.255.255.0
broadcast   192.168.202.255
bridge_ports none
bridge_fd 0
bridge_maxwait 0

The problem I'm facing that in VE (for example with CTID 202) I can ping or
query 192.168.203.1 which is on HN of course, but I thought it shouldn't be
reachable.

Here is route table and ifconfig on CTID 202:

# ip r
default dev lo  scope link
# ifconfig -a
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:84021 errors:0 dropped:0 overruns:0 frame:0
  TX packets:84021 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:5045068 (4.8 MiB)  TX bytes:5045068 (4.8 MiB)

venet0Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  BROADCAST POINTOPOINT NOARP  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


So I guess it's going through lo device? Why and how can I block this?

Many thanks.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users