Galia Lisovskaya | 1 Jul 2010 01:36
Picon

Re: vzmigrate and named containers

Hello,

It's fixed in last release : http://bugzilla.openvz.org/show_bug.cgi?id=1333

:(

2010/6/30 Alan Young <alan.young@...>:
> I'm using vzmigrate to handle migration of containers from one HN to
> another.  It works without a hitch.
>
> My only complaint is that it doesn't check for the existence of a
> container with the same name on the destination node.  I can fix that
> easily enough, but I'd like to submit a patch.  Where would I do that?
> --
> Alan

--

-- 
Galina Lisovskaya
Alan Young | 1 Jul 2010 03:43

Re: vzmigrate and named containers

On Wed, Jun 30, 2010 at 17:36, Galia Lisovskaya <inbox@...> wrote:
> It's fixed in last release : http://bugzilla.openvz.org/show_bug.cgi?id=1333

Thank you.  That makes my job a little easier.
--

-- 
Alan
Roman Haefeli | 1 Jul 2010 09:17
Picon
Favicon

Re: how to let a CT configure it's IP address?

On Wed, 2010-06-30 at 17:36 +1000, Daniel Pittman wrote:
> Roman Haefeli <reduzierer@...> writes:
> 
> > We would like to build a mysql-cluster with two mysql-servers in a
> > master-master configuration. We're trying to use mysql-mmm [1] for a
> > fail-over setup. Both mysql-servers are running in their own container on
> > two different host nodes.
> 
> [...]
> 
> > So I tried to use veth instead (according to [2]). I configured on each
> > mysql-server a virtual ethernet device. But then I realized that in order to
> > make the virtual device on the host node accessible to the world, I need to
> > manually add a route on CT0.
> 
> ...or add the veth device on CT0 to a software bridge with the physical
> device, which is the most common way to implement this.  Look for 'vznetaddbr'
> here: http://wiki.openvz.org/Virtual_Ethernet_device
> 
> That way your container VETH behaves as if it is a physical Ethernet device
> connected to the external network, which is what you probably want.

Exactly.

> Be aware, though: Linux can still apply iptables firewalling to a software
> bridge interface, so make sure that doesn't get in the way in your setup, if
> CT0 has firewall rules applied.

Hm, I indeed have trouble making it work. I'll check the iptables...
Many thanks for your help!
(Continue reading)

Alfred Sawaya | 1 Jul 2010 11:11
Picon

Re: Give kernel modules access to VE

Le 30/06/2010 16:35, Galia Lisovskaya a écrit :
> 2010/6/30 Alfred Sawaya<wildhuji.lists@...>:
>    
>> Le 25/06/2010 20:29, Galia Lisovskaya a écrit :
>>      
>>> To some devices(in devfs) you may take access, see examples:
>>>
>>> http://wiki.openvz.org/USB_Printing_in_VE
>>> http://wiki.openvz.org/Installing_Trixbox_2.0_in_CentOS_VE
>>> http://wiki.openvz.org/VPN_via_the_TUN/TAP_device
>>>
>>>
>>>        
>> Well, I see on Wikipedia that OpenVZ doesn't support IPSec and L2TP into a
>> VE, and it was just what I wanted to do by inserting kernel module into a
>> VE...
>>      
> Wy you want use VPN inside _container_ (not VirtualMachine)? You may
> use IPsec on hardware node...
> We use IPsec beetween HW nodes in VE0
>
>    
Actually, we use Xen. We have an IPSec connection to our concentror on 
Dom0 and a IPSec connection into a vm for clients access purpose. We 
want separating clients access to our access (by isolating clients into 
a vm).
But we virtualize debian into debian, so using OpenVZ seems to be a 
great thing.
> But, we use OpenVPN server (it's user-mode part) inside container,
> and, please see this:
(Continue reading)

Scott Dowdle | 1 Jul 2010 21:22
Favicon

Re: [Announce] New beta templates released: fedora-13

Kir,

----- Original Message -----
> OpenVZ project has released beta templates for Fedora 13.
> Please note that these are still beta quality.
> 
> Download
> =========
> http://wiki.openvz.org/Download/template/precreated/beta

Both of them worked great for me.

The only thing I noticed that was odd was that when doing any type of yum operation both (x86 and x86_64) told
me that there was a previous transaction that needed to be completed and to run yum-complete-transaction
to finish them up.  yum-complete-transaction is part of the yum-utils package which is NOT installed...
so I installed it and completed the transaction.

I did a few changes and am in the process of uploading some new Fedora 13 OS Templates to contrib.  The changes include:

1) Installed mc, links, nano, and yum-utils

2) Removed samba*

3) Edited /etc/httpd/conf/httpd.conf to put Apache's config back to a more stock configuration since the
one provided is extremely minimalistic.

Thanks for the new OS Templates!

TYL,
--

-- 
(Continue reading)

Stanichenko Marat | 2 Jul 2010 16:04
Favicon

Re: HA: strange network problem

Nirmal Guhan wrote on 25.06.2010 20:40:
> 2010/3/15 Marat Stanichenko <mstanichenko@...>:
>   
>> Hi,
>>
>> as far as I understand, your network configuration is based on simple venet0 interface.
>> Is that true? I suppose that you are faced with arp-problem but could you please elaborate
>> your network configuration a little bit so one can understand what the exact environment is.
>> It may be important if you are using several route tables.
>> "ip a l", "ip  route list table all", "ip rule list", "arp -n" would be enough I suppose.
>>
>> Let me give you a hint so that you will be able to cope with the problem by yourself.
>> venet0 is working according the following principle. If a remote machine is willing to communicate
>> with a VE it send "arp-who has" request. This type of request reaches a HN and the HN is sending
>> "arp reply" to the remote machine (that's why "arp -n" output should contain information about VE).
>> Then the remote machine sends network packets to the HN but because of the additional route
>> (see "ip route list" output) all packets are going inside VE through the HN. That's the principle of venet0
>> interface.
>>     
>
> Does this VE->HN happen within the driver/kernel or does each packet
> for VE go to some user level process in HN and then sent to the VE ?
> Kindly clarify.
>
> --Nirmal
>   
There is NO user level process on the HN that receives VE's packets.
Everything processed inside the kernel.

-- Stanichenko Marat
(Continue reading)

Benjamin Henrion | 5 Jul 2010 17:13

vzcpt kernel module crash while trying to dump with "vzctl chkpnt"

Hi,

I am running a Debian Lenny kernel, and I am trying to simply dump a
container, and the kernel module named vzcpt crash:
# cat /proc/version
Linux version 2.6.32-5-openvz-686 (Debian 2.6.32-15)
(ben@...) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Tue
Jun 1 06:52:26 UTC 2010

# vzctl chkpnt 103 --dump --dumpfile /var/lib/vz/dump/Dump.103
Setting up checkpoint...
        join context..

(and then it hangs the shell)

I have submitted a bug here:

http://bugzilla.openvz.org/show_bug.cgi?id=1573

Does anybody has ever experienced this?

Best,

==========================================================================
[25342.211353] BUG: unable to handle kernel paging request at 0a7e1000
[25342.211362] IP: [<f88031c7>] cpt_dump_snmp_stat+0x63/0x119 [vzcpt]
[25342.211374] *pdpt = 00000000174f8001 *pde = 0000000000000000
[25342.211379] Oops: 0000 [#1] SMP
[25342.211384] last sysfs file:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
(Continue reading)

jehan procaccia | 5 Jul 2010 22:59
Picon

kernel 2.6.18-194.3.1.el5 boot freeze

hello,

after upgrading to ovzkernel-2.6.18-194.3.1.el5.028stab069.6 , my Dell 
Poweredge 2950 doesn't boot anymore
It freezes at the very start of the kernel boot sequence:

....
Net: registered protocol family 1
Net: registered protocol family 17
Using IPI shortcut mode
Time: hpet clocksource has been installed
Initializing network drop monitor service
Freeing unused kernel memory: (00764000-007a1000) 244k freed
Wrtite protecting the kernel read-only data: 427k
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c

it freezes here ! apprently doing nothing !?

I set back in grub my previous 
ovzkernel-2.6.18-164.15.1.el5.028stab068.9 and it works fine again.
but I would appreciate to be able to run the latest kernel .
Any known bugs or problem with that 
ovzkernel-2.6.18-194.3.1.el5.028stab069.6 ?

Thanks.
(Continue reading)

Kelvin Raywood | 6 Jul 2010 00:55
Picon
Favicon

iptables MASQUERADE and MARK

We're using OpenVZ to host firewalls for multiple VLANs and it's working 
out really well in the cases where we write the iptables rules 
ourselves.  We add the network interface of each VLAN directly to a VPS 
and use a bridge on the other side.

For some VLANs, we want to use iptables rules generated by some other 
software.    One of these use both ipt_MASQUERADE and ipt_MARK.  It 
seems as though MASQUERADE is now working in 
ovzkernel-2.6.18-194.3.1.el5.028stab069.6 although vzctl-3.0.24-1 
doesn't recognize it. However, ipt_MARK is not OpenVZ-ised so we have to 
run a couple of separate stand-alone non-OpenVZ boxes for the VLANs that 
use this software.  Unfortunately, the software is not easily hackable 
making one box per VLAN necessary.

I searched the OpenVZ bugzilla but couldn't find any entries for 
ipt_MARK.  Does anyone know if this module will be OpenVZ-ised in some 
future kernel ?

If not, I'll add a feature request.

BTW, the message quoted below did not receive a response on the list but 
I confirm that MASQUERADE is now virtualized but the tools don't yet 
know.  So you have to use some non-OpenVZ method to ensure that it gets 
loaded.  On CentOS-5, I drop short scripts in /etc/sysconfig/modules/ to 
ensure that various modules are loaded.

Cheers,

--
Kelvin Raywood
(Continue reading)

Kir Kolyshkin | 6 Jul 2010 16:44
Favicon

Re: vzcpt kernel module crash while trying to dump with "vzctl chkpnt"

On 07/05/2010 07:13 PM, Benjamin Henrion wrote:
> Hi,
>
> I am running a Debian Lenny kernel, and I am trying to simply dump a
> container, and the kernel module named vzcpt crash:
> # cat /proc/version
> Linux version 2.6.32-5-openvz-686 (Debian 2.6.32-15)
> (ben@...) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Tue
> Jun 1 06:52:26 UTC 2010
>
> # vzctl chkpnt 103 --dump --dumpfile /var/lib/vz/dump/Dump.103
> Setting up checkpoint...
>          join context..
>
> (and then it hangs the shell)
>
> I have submitted a bug here:
>
> http://bugzilla.openvz.org/show_bug.cgi?id=1573
>
> Does anybody has ever experienced this?
>    

Ben,

Thank you for report! This is a known bug, already fixed
about 2 weeks ago in our kernel. I have asked Debian
kernel maintainers to update their OpenVZ kernel.

Regards,
(Continue reading)


Gmane