OVH Community, your new community space.

OVH + OpenVZ + failover + venet


Thelen
20-10-2012, 10:25
Not sure what you mean Daz, but CentOS6.3 custom installed (not OVH) is what is working currently.

Christian, yes don't assign virtual mac, just setup container and use vzctl set 101 --ipadd BLAH and it will work fine venet style.

I will shortly try to get kvm to work as well, which i assume should work basically the same if it uses venet type thing. otherwise mac might be needed.

and yea, the 5 minute thing is a PITA lol. at least splitting/moving ips you can do as much as you want

this might all become redundant on monday though given the new plans and possibly worse pricing, in which case i'll be shifting to the other couple providers that are almost as cheap as OVH, and might become cheaper on monday.

cartwright118
18-10-2012, 14:59
Quote Originally Posted by DigitalDaz
Just for future reference, what distro did you use that just works out of the box and is it the stock OVH install?



Two reasons why I wouldn't use the virtual macs unless you really need to.

Firstly its more work and needs to be changed within the container but far more important for me is this:

If you ever need to failover to another box you will need to reroute the virtual macs in the manager to the new server. Now you may think you will have to do that anyway even with a failover IP and its true, you will. Rerouting an IP with a failover mac attached quite often breaks and you will end up needing to get them fixed with a support ticket.

Also, and something we will probably see more of now that OVH are charging per individual IP, many people will start breaking up more RIPE blocks. If you need to failover and a virtual mac is involved, the OVH manager will only allow you one operation that is virtual mac related within a five minute period. This means that if you have twelve to shift individually, it will take you an hour at least just to reroute the IPs. Just bear it in mind when choosing between veth and venet.
You have saved me a load of time! Virtual macs are a complete pain in the ass. You are right, every time I want to change an IP...it takes 5 minutes. On more than a couple of occasions I have had to contact support because the Virtual Mac hasn't worked properly. I use Virtual Macs because it was how OVH told me to do it...I thought that 'was the way' - 'the correct way' (so yeah, I apologise @Thelan for the confusion)

How would you configure OpenVZ then not to use virtual mac? - Just don't assign a virtual MAC to an IP and then configure the IP address in the guest OS?

Thanks
Christian

DigitalDaz
18-10-2012, 08:26
Quote Originally Posted by Thelen
un-uckfing-believable. it was the firewall...

/etc/init.d/iptables stop

nowhere on Openvz.org guide, nowhere on 5 other guides, NOWHERE DOES IT MENTION TO TURN IT OFF.

works fine now.

and yes, you don't/shouldn't use virtual mac in OVH panel.
Just for future reference, what distro did you use that just works out of the box and is it the stock OVH install?

I always assign virtual macs to mine, without fail. As it never works without it. In actual fact one day I had made a mistake with the MAC, OVH did an intervention and charged me. I always make sure it's done correctly now haha.
Two reasons why I wouldn't use the virtual macs unless you really need to.

Firstly its more work and needs to be changed within the container but far more important for me is this:

If you ever need to failover to another box you will need to reroute the virtual macs in the manager to the new server. Now you may think you will have to do that anyway even with a failover IP and its true, you will. Rerouting an IP with a failover mac attached quite often breaks and you will end up needing to get them fixed with a support ticket.

Also, and something we will probably see more of now that OVH are charging per individual IP, many people will start breaking up more RIPE blocks. If you need to failover and a virtual mac is involved, the OVH manager will only allow you one operation that is virtual mac related within a five minute period. This means that if you have twelve to shift individually, it will take you an hour at least just to reroute the IPs. Just bear it in mind when choosing between veth and venet.

cartwright118
18-10-2012, 07:29
I always assign virtual macs to mine, without fail. As it never works without it. In actual fact one day I had made a mistake with the MAC, OVH did an intervention and charged me. I always make sure it's done correctly now haha.

To begin with I followed the guide provided by OVH.

Using the OVH guide I don't very often have issues with OpenVZ containers.

I never used to use OpenVZ, I used KVM. Maybe that's why I think I need to use VirtualMAC? I just automatically added it to OpenVZ and it works. Didn't try it without the MAC on OpenVZ.

Thelen
18-10-2012, 02:31
un-uckfing-believable. it was the firewall...

/etc/init.d/iptables stop

nowhere on Openvz.org guide, nowhere on 5 other guides, NOWHERE DOES IT MENTION TO TURN IT OFF.

works fine now.

and yes, you don't/shouldn't use virtual mac in OVH panel.

DigitalDaz
17-10-2012, 20:56
Quote Originally Posted by 3r1c
OpenVZ does not use virtual MACs.
If you have set a virtual mac for the IP in the OVH control panel you need to remove it.
You should not add the IP to the interface, let OVZ take care of it.

OpenVZ works fine for me on OVH, but I wipe HDD and do a clean reinstall on all my servers with a official centos ISO.
The reason it doesn't work is probably due to OVH modified kernels.
I was actually only reading an article about LXC earlier, and it said, "OpenVZ is more mature but it requires a kernel patch to be applied and few distros provide it out of the box."

Is using Proxmox an option and just using the OpenVZ part. The venet works perfectly right out of the box with OVH as does veth with the virtual macs.

3r1c
17-10-2012, 18:05
OpenVZ does not use virtual MACs.
If you have set a virtual mac for the IP in the OVH control panel you need to remove it.
You should not add the IP to the interface, let OVZ take care of it.

OpenVZ works fine for me on OVH, but I wipe HDD and do a clean reinstall on all my servers with a official centos ISO.
The reason it doesn't work is probably due to OVH modified kernels.

wii89
17-10-2012, 14:31
Ovh have a problem with ip fallovers http://status.ovh.co.uk/?do=details&id=3396

Thelen
17-10-2012, 09:52
Nope just that server. no idea what that mac is.

this isn't really to do with ovh per se, as in it seems its failing to even assign the ip on an openvz level :/

cartwright118
17-10-2012, 08:38
Have you got that failover IP '178.33.28.113' assigned anywhere else?

What is this mac address > 00:00:0c:9f:f0:01

I had a problem once where I assigned an IP/Mac as a spare IP in a webhosting control panel. (Forgot all about it) and then tried to use that spare IP (as it was spare) on a VPS. Which obviously didn't work and it errored saying that it was a duplicate ip. I had completely forgotten that I had assigned it to this control panel.

The error message 'arpsend: 178.33.28.113 is detected on another computer : 00:00:0c:9f:f0:01' seems to be reminding me of that occasion.

Christian.

Thelen
17-10-2012, 06:38
Didn't mask anything.

Yes OVH does, but it isn't even getting that far.

carwright yea that works fine on my solusvm config (speaking of, I'll login to the box and see how it is configured ), and I believe I did try that, but not sure I'll try again.

cartwright118
16-10-2012, 18:04
I usually just create my container edit ifcfg-eth0 with

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
IPV6INIT=no
PEERDNS=yes
TYPE=Ethernet
NETMASK=255.255.255.255
IPADDR=IP Failover
GATEWAY=Dedicated Server IP but end in .254
ARP=yes
HWADDR=Your Virtual Mac Address

In the HWADDR field I use the one given to me in the OVH panel when assigning a Failover

Also I create a route-eth0 and edit with

Dedicated Server IP but end in .254 dev eth0
default via Dedicated Server IP but end in .254 dev eth0

cartwright118
16-10-2012, 18:02
Hi Thelan,

I dunno whether you have deliberately masked out the HWaddr.

It doesn't seem to be set in the container? Doesn't the OVH system prevent containers from connecting to the internet unless you use one of their provided MAC Addresses?

Christian

Thelen
16-10-2012, 06:13
Trying to get OVZ to work using default venet setup of the containers, however doesn't seem very happy:

vzctl start 113
Starting container ...
Container is mounted
Adding IP address(es): 178.33.28.113
arpsend: 178.33.28.113 is detected on another computer : 00:00:0c:9f:f0:01
vps-net_add WARNING: arpsend -c 1 -w 1 -D -e 178.33.28.113 eth0 FAILED

from the container:
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 94.23.247.162 icmp_seq=1 Destination Host Prohibited


CONTAINER:
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1576 (1.5 KiB) TX bytes:1350 (1.3 KiB)

venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:178.33.28.113 P-t-P:178.33.28.113 Bcast:178.33.28.113 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1


ip r l
169.254.0.0/16 dev venet0 scope link metric 1002
default dev venet0 scope link

HOST:
eth0 Link encap:Ethernet HWaddr 00:25:90:22F:CE
inet addr:94.23.247.162 Bcast:94.23.247.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe22:dfce/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:997 errors:0 dropped:0 overruns:0 frame:0
TX packets:783 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:86832 (84.7 KiB) TX bytes:140132 (136.8 KiB)
Interrupt:16 Memory:fbce0000-fbd00000


venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::1/128 Scope:Link
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:59 errors:0 dropped:0 overruns:0 frame:0
TX packets:49 errors:0 dropped:3 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4284 (4.1 KiB) TX bytes:4918 (4.8 KiB)



ip r l
178.33.28.113 dev venet0 scope link
94.23.247.0/24 dev eth0 proto kernel scope link src 94.23.247.162
169.254.0.0/16 dev eth0 scope link metric 1002
default via 94.23.247.254 dev eth0


I've tried about 4 different combinations of stuff, decided to just try get the default OVZ stuff to work. so unfortunately means probably the panel solutions like promox would make it work, but not in this case :/