Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


OpenVZ troubles
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

OpenVZ troubles

I recently setup a CentOS 6.4 server with OpenVZ, and I am having troubles with my ip allocation.
I have 5 ip addresses(ipv4) on the server, and I setup the pool by making a ifcfg-eth0-range0 file.

The five addresses are like:

192.168.1.0

192.168.1.1

192.168.1.2

192.168.1.3

192.168.1.4

Now after doing this, all of my ip addresses starting responding to pings, as compared to earlier, when only the default/first ip addresses was responding. All, but one. The second one in the list is not responding to pings.
Before making the file, I installed openvz-web-panel, added the ip pool in there, but started from the second address, as the first one is in use by the server itself, and it is the ip that ovz web panel is running on. I created a new vps with the second address assigned to it, but as it did not respond to pings, I went ahead to do what I first mentioned, the range0 file method.
I don't know where I'm going wrong, as the second ip(192.168.1.1) is not responding to pings. It responds to pings only when I ping it from the server itself, with a response time of 0.064ms. So I guess the ip is working.
There is another problem. The ip's don't bind to the vps, but stay attached to the server itself. So if I try to ssh, I ssh into the server, and not the vps.
Any help would be appreciated.

Comments

  • 5n1p5n1p Member
    edited October 2013

    So you have containers with local IPv4 and you want to assign one of extra IP's you have for that server, if I understand this. To assign IPv4 to you container an your host do:

    vzctl set container_ID --ipadd your_extra_ip_here --save

    container_ID you have that in your webpanel if you created it like that so this should be:

    vzctl set 102 --ipadd 1.2.3.4 --save

    hope this helps.

  • Remove the ifcfg-eth0-range0 file(s) as it will bind IPs to the server, not to the containers. To bind IP(s) to VPS, do as above said.

  • So my question first is venet active? Run a ifconfig. Sounds like your ip allocation is on a vlan which you don't need to bind all the address to your eth0. You just assign the address to your vm machine then via vzctl. If your provider does not route the ips through a vlan then your gonna have to use a routed bridge setup.

  • @5n1p said:
    So you have containers with local IPv4 and you want to assign one of extra IP's you have for that server, if I understand this. To assign IPv4 to you container an your host do:

    vzctl set container_ID --ipadd your_extra_ip_here --save

    container_ID you have that in your webpanel if you created it like that so this should be:

    vzctl set 102 --ipadd 1.2.3.4 --save

    hope this helps.

    No, I just used those addresses as an example, I have 5 public IPv4 addresses.Will try this out soon.

    @DalComp said:
    Remove the ifcfg-eth0-range0 file(s) as it will bind IPs to the server, not to the containers. To bind IP(s) to VPS, do as above said.

    What is they are public IP's?

    @Ian_ said:
    So my question first is venet active? Run a ifconfig. Sounds like your ip allocation is on a vlan which you don't need to bind all the address to your eth0. You just assign the address to your vm machine then via vzctl. If your provider does not route the ips through a vlan then your gonna have to use a routed bridge setup.

    All of the ip addresses are assigned to eth0, like eth0:x. There is another adapter called venet0-00, with the following values:

    inet6 addr: fe80::1/128

    So I guess its the local IPv6 adapter.

  • Ian_Ian_ Member
    edited October 2013

    No do not bind the additional ip addresses to eth0. Remove the ifcfg-eth0-range0. If your remaining ips are on a vlan just create a vm and assign the ip with vzctl. Thats it! If your using openvz web panel just add the remaining ips to the pool and create a vm from with in the panel and it will do the rest.

  • And how do I know if the remaining ip's are on a vlan? I do have a subnet mask and gateway for those addresses.

  • FrankZFrankZ Veteran
    edited October 2013

    192.168.1.0

    192.168.1.1

    192.168.1.2

    192.168.1.3

    192.168.1.4

    Your example is a vlan.

    192.168.1.0

    192.8.1.1

    192.8.1.2

    192.16.1.3

    192.18.1.4

    These ips are not on the same vlan

    EDIT:
    If you ips are not on the same vlan enter this to make openVZ see them

    sed -i 's/NEIGHBOUR_DEVS=detect/NEIGHBOUR_DEVS=all/g' /etc/vz/vz.conf

  • My IPs are on the the same vlan then.

  • Well do what's been told to u and it will work.

  • dhamaniasaddhamaniasad Member
    edited October 2013

    I deleted the eth0-range and managed to get all but the 192.168.1.1 ip to bind to it. Obviously, 192.168.1.1 is a decoy ip here. What happened is that I accidentally ran this :

    vzctl set 102 --ipadd 192.168.1.1 --save

    Where I did not have any vps with id 102.
    This was the response:
    Warning: distribution not specified in CT config, using defaults from /etc/vz/dists/default
    WARNING: /etc/vz/conf/102.conf not found: No such file or directory

    I ran vzctl set 102 --ipdel all --save then, got this response:
    Warning: distribution not specified in CT config, using defaults from /etc/vz/dists/default
    WARNING: /etc/vz/conf/102.conf not found: No such file or directory
    CT configuration saved to /etc/vz/conf/102.conf

    I am unable to bind the 192.168.1.1 to another vps now.

    I tried running this : vzctl set 1236 --ipadd 192.168.1.1 --save
    Got this response:
    CT configuration saved to /etc/vz/conf/1236.conf
    You have mail in /var/spool/mail/root

    But I am unable to start the container. What should I do now?

  • Have you tried:

    vzctl start 1236

    Other then this do you really need to use 192.168.1.1. just use some other address, can you bind any 192.168.1.10 to container ?

  • @5n1p said:
    Have you tried:

    vzctl start 1236

    Other then this do you really need to use 192.168.1.1. just use some other address, can you bind any 192.168.1.10 to container ?

    I removed the ip address from the VPS using vzctl, it was bound to 1234, not 1236. After doing this, and remaking 1236, it boots up just fine, but it doesn't respond to even pings.
    I am using 192.168.1.1 as a decoy, the actual address is a public ipv4 address, and I only have 5, and 4 others are in use now. So I need to use that address.

  • Not sure what you mean by decoy, but if that means that it is IP from your host node then you cant use same address on your container. So first add some local IP for container and then do on host node:

    iptables -t nat -A POSTROUTING -s vm_local_IP_pool -o eth0 -j SNAT --to your_public_ip_address

    now log in your container from your host node with ssh to localIP and see if you can ping anything outside for example google. To make your container accept incoming ssh connection you need to use iptables on host to forward some port:

    iptables -t nat -A PREROUTING -p tcp -d your_public_ip_address --dport 10022 \
    -i eth0 -j DNAT --to-vm_local_IP:22

    now you can ssh to your vm with host IP on port 10022. Not sure this is what you are looking for but if yes don't forget to save iptables.

  • @5n1p said:
    Not sure what you mean by decoy, but if that means that it is IP from your host node then you cant use same address on your container. So first add some local IP for container and then do on host node:

    iptables -t nat -A POSTROUTING -s vm_local_IP_pool -o eth0 -j SNAT --to your_public_ip_address

    now log in your container from your host node with ssh to localIP and see if you can ping anything outside for example google. To make your container accept incoming ssh connection you need to use iptables on host to forward some port:

    iptables -t nat -A PREROUTING -p tcp -d your_public_ip_address --dport 10022 \
    -i eth0 -j DNAT --to-vm_local_IP:22

    now you can ssh to your vm with host IP on port 10022. Not sure this is what you are looking for but if yes don't forget to save iptables.

    What I mean by decoy ip is that this is not the real ip. My real ip is something like this : 208.209.208.1(yeah, decoy again). And my host node has an ip of 208.209.208.0, so this is not the ip my host node is using. I'm just looking to assign this ip to the VPS, but I could use your method for NAT, right?

  • Oh, then just assign 192.168.10.1 to your container and do nat from your host node.

  • I have iptables running, but there are no rules configured that could be preventing me from using that ip. All other ip's work instantaneously. No matter how many times I create and destroy a container.

  • dhamaniasaddhamaniasad Member
    edited October 2013

    Here is the output of the arp command :


    Address HWtype HWaddress Flags Mask Iface
    208.209.208.52 (incomplete) eth0
    208.209.208.54 (incomplete) eth0
    208.209.208.49 ether 00:04:9b:f2:b0:00 C eth0
    208.209.208.53 (incomplete) eth0
    208.209.208.51 * * MP eth0

    Only the ip not working has this *

  • I attached all the ip's to containers, and all of them got the *'s, and even the MP flag. But still, only the 51 is not working. It is attached to a vps, and that container is running. I can even connect to the container with the ip 51 from within the host node using ssh, not a single problem with that, but I can't ping it or connect to it from the outside world.

  • Well only thing that is left to do is to open ticket with your provider, I don't get why only 1 IP wont work, and have no idea.

  • @5n1p said:
    Well only thing that is left to do is to open ticket with your provider, I don't get why only 1 IP wont work, and have no idea.

    Ok, will do.

  • When it resolves don't forget to post how here :)

  • @5n1p said:
    When it resolves don't forget to post how here :)

    Its been resolved, they say it was nulled from an old client. Don't know what that means though.

  • It means they null routed the IP before you they gave it to you. Meaning the IP would not be useable no matter what you did.

    The client before you likely had some trouble with that IP and they solved it by null routing it. They just never removed this before redeploying the IP to you.

  • @AuroraZ said:
    It means they null routed the IP before you they gave it to you. Meaning the IP would not be useable no matter what you did.

    The client before you likely had some trouble with that IP and they solved it by null routing it. They just never removed this before redeploying the IP to you.

    Oh, ok. But I still don't get why it would be accessible from within the host node.

Sign In or Register to comment.